Page Comparison

...

STOCK_CARDS_VIEW (supervision type): 
Can view all the stock cards and line items for any Orderable that is part of a specified Program and HomeFacility/Node.

...

• • Viewing the stock card with all its line items, including all historical line items, and printing
    
  • Viewing and printing an SOH summary showing a stock card's SOH

STOCK_CARD_TEMPLATES_MANAGE (admin type): 
Can configure the stock card template.

Applies to:

• • Configure the stock card template (a global template that applies for all programs)
    Assumption: The stock card template is the same for all programs. In other words, in one OpenLMIS implementation there is only one template.

STOCK_SETTINGS_MANAGE (admin type): 
Can configure settings for the stock service (not including the stock card template).

Applies to:

• • Configure (add, edit) organizations, sources/destinations, reasons, stock card template

STOCK_SOURCES_MANAGE

STOCK_DESTINATIONS_MANAGE

STOCK_CARD_LINE_ITEM_REASONS_MANAGE

ORGANIZATIONS_MANAGE

STOCK_EVENT_CREATE

Rights to Remove

A handful of STOCK_* rights are already built into the bootstrap data, but we suggest removing them for 3.1 (see No Permissions Checks section below):

• STOCK_SOURCES_VIEW 
• STOCK_DESTINATIONS_VIEW
  
• STOCK_CARD_LINE_ITEM_REASONS_VIEW
  

No Permissions Checks

These endpoints will be visible to all logged-in users (no rights need to be checked other than a valid login token):

• GET /api/organizations
• GET /api/stockCardLineItemReasons
• GET /api/reasonCategories (or reasonTypes)
• GET /api/validReasons
• GET /api/validDestinations
• GET /api/validSources
  
  

NOT in v3.1

• Creating a Stock Card: This is not a right, because we expect the system will create a stock card on-the-fly on an as-needed basis. This might happen during a physical inventory, or even while recording an adjustment. The other rights cover those cases. For example, if a user can adjust stock for Program A at Facility Z, then their activities in the system can also result in creation of a stock card at A and Z.
  
• Editing a Stock Card: This is not a right, because currently there is nothing to edit. The stock card has no fields other than its identification as a combination of a Program, Product (Orderable) and Facility. It also has Line Items, but those are covered above.
  
• Issuing and Receiving: There are not specific rights for this. We may decide in the future to create a new right when this functionality is added.
  
• Receiving by POD: (also not in scope yet)

...

1. Do we need any other mechanisms for users to see across multiple programs? or across multiple facilities? The scheme would require assigning multiple rights if the user needed permissions to multiple facilities. The scheme above would involve using supervisory nodes to give permissions to multiple facilities (any section of the supervisory hierarchy).
   
   1. Proposed Answer: This is good enough for now. It is a little clunky, because there is no way to say "assign this user for ALL programs at Facility X". But that's okay.
2. We are not sure if some existing code has endpoints that are were removed from scope during the workshop. For example, the stock card template feature was already built, and there is an endpoint for it, but we are not sure if it is in scope for v3.1 or not. Another example is the valid destinations endpoint, which is only needed for Issue/Receive functionality.
   1. Proposed Answer: Remove the endpoints from the RAML before the release. That way they will not be registered by Consul. The code will be there (in Java source), but nobody can hit those endpoints.