View Source

Target release	Release name or number
Epic
Document status
Document owner	Sam Im (Deactivated)
Technical Lead	Josh Zamor

Goals/Scope

We need a way for an Administrator to create a special type of User which:

is for a system such as ColdTrace to use our API
doesn’t have a password (uses system generated web token)
ability to generate new API Key
has basic permissions which are essentially Administrator type privileges to things like: Admin CCE, Admin Requisition etc.

We want to leverage our existing RBAC as much as possible for this. The screens however will have some significant differences from our current person-oriented screens.

Background

Are there any country specific features that should be noted? Who are the personas? Who are the users that will be interacting with this functionality? What are their challenges, responsibilities, and level of connectivity? These personas are intended to be representative archetypes of the key stakeholders who will participate in theses workflows/scenarios.

Assumptions

What are technical or business specific details and characteristics that should be known to explain the environment? List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).

User Stories

Short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

#

Title

User Story

Label

Importance

Jira ticket

1

Manage API keys

As an administrator I need to manage API keys so that an external partner can access OpenLMIS.

Acceptance Criteria:

Generate new API keys
View history of API keys
Remove/delete API keys (these are made inactive)

Must Have

2

Manage multiple partners' API keys

As an administrator I want to assign API keys to different external partners who access OpenLMIS.

Acceptance Criteria:

Partners are identified with a name in the API Key table (different partners have different API Keys depending on their access).

Nice to Have

Diagrams

Include any business process mapping, mockups, diagrams or visual designs relating to these requirements. Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.

Dependencies

Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.

Description	Link
Name of story or release	Link to JIRA

Open Questions

Initial communication between stakeholders and the development team to help understand scope and estimates.

Below is a list of questions to be addressed as a result of this requirements document:

#	Question	Outcome	Status
1	Should this process support the admin setting up a username for any new system that requests access?	Communicate the decision reached	Open, In Progress, Closed, and date of closure
2	What types of permissions will be included in this service account? Are there multiple types or levels of service accounts that we need? Do we need new permissions? Are new permissions being created for Fulfillment (that would be dependencies to completing this feature)? Are we only allowing viewing or does this service account need edit permissions also?
3	Is there a logging or auditing process that we will use to track requests from this service account, or any of these types of service accounts that the administrator creates?
4

Out of Scope

Automated notification to external partner that their API Key has been changed