Page Comparison

...

• 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)

Open Questions

...

Dropdown Lists for Program, Facility and Orderable

Create a Physical Inventory—Program Dropdown List and Facility Dropdown List

When starting to create a new physical inventory (see this mockup: Mock Ups-physical inventory program name): Show only the Programs where the current user has STOCK_INVENTORIES_EDIT right. Use the /api/users/{userId}/hasRight endpoint in ReferenceData to check rights.

If* there is also a facility already selected, then filter the Programs dropdown to only show Programs where the current user has the STOCK_INVENTORIES_EDIT right for that facility (meaning their home facility if the Right is a Home Facility right, or meaning all the facilities below a Supervisory Node in the hierarchy if the Right is at a Supervisory Node).

*The current mockups do not have a Facility field shown when creating a new physical inventory, but I believe you must also pick a Facility in order to create a physical inventory. The facility dropdown will show all the facilities where the current user has STOCK_INVENTORIES_EDIT right. If there is already a Program selected, then filter the Facilities dropdown to only Facilities where the user has STOCK_INVENTORIES_EDIT right for the chosen Program.

In summary, the combination of Program and Facility dropdowns will only let the user create a new physical inventory for a valid combination of Program and Facility where they have the STOCK_INVENTORIES_EDIT right.

While Conducting Physical Inventory—Program Dropdown List

The mockups (like this one) do still show a Programs dropdown on the top left while the user is conducting a physical inventory. It's my understanding that dropdown would offer a filtering feature to filter the grid of products while the user is conducting an inventory. But that filter is only needed later if/when we decide to allow a physical inventory to be conducted on multiple programs at once. For now, we might not need this filter at all (I added a new comment on the mockups page about that too).

Regardless of all that, if we do decide to have a Programs filter on this page while conducting a Physical Inventory now, then it would simply show all of the Programs that were included in this physical inventory. So if the physical inventory contains 4 programs, those 4 programs would show on the dropdown to filter the grid. We do not need to check permissions for this dropdown—just use the program values that are in this physical inventory they are editing. The system would have already checked permissions (STOCK_INVENTORIES_EDIT) to let the user in to edit this physical inventory.

While Conducting Physical Inventory—Orderable Dropdown List (in modal/popup when Adding Products)

While conducting an inventory, the Add button allows the user to add more products to the inventory. It opens a modal popup window (see mockup) for selecting and adding a product one at a time. This dropdown is called "Product" for end-users but it is a list of Orderables from OpenLMIS ReferenceData. The list should contain Orderables from the Reference Data endpoint /api/orderables /api/facilities/{id}/approvedProducts (use the facility ID of this inventory and pass in the Program ID to make the query). The dropdown list should only display Orderables that are approved for the Program and FacilityType of this inventory. The list should not show the Orderables already in the inventory, because you cannot Add an item again that is already in the inventory (or maybe the list does show these, but does not allow you to select them because it might give some visual indication that this is already in the inventory).

SOH Summary Page—Program Dropdown List and Facility Dropdown List

When viewing SOH Summary page (see this mockup: Mock Ups-SOH Summary page), the user can pick a Program and Facility. These dropdown lists should be limited by the user's STOCK_CARDS_VIEW rights. Only show Programs and Facilities where the user has the right, and when the user picks a choice on one dropdown we can filter the other dropdown (similar to above).

Create Adjustment—Program Dropdown List and Facility Dropdown List

When creating an adjustment (no mockup yet), the user also picks a Program and Facility from dropdowns. These dropdowns should be limited by the user's STOCK_ADJUST rights. As above, only show Programs and Facilities where the user has that right, and when the user picks a choice on one dropdown then filter the other dropdown.

View Physical Inventory

We do not yet have mockups for any screens to View a past Physical Inventory. But if those screens are coming, they will likely include Program and Facility dropdowns. These dropdowns should be limited by the user's STOCK_INVENTORIES_VIEW right. And again, as above, picking on one dropdown should filter the other dropdown.

Management Screen Dropdowns

For Admins going into administration screens to manage reasons, organizations, sources/destinations, etc, all of those rights above are for all Programs and all Facilities. So the administrators would not need to be picking from reduced or filtered dropdown lists. Generally, on these administration screens the admin would get a list of all Programs in the whole system, all Facilities, all Orderables, etc.

Open Questions

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.