2017-02-27 Meeting Notes




  • Analysis done for Panda Sprint 6 stories

Discussion items


10 min

OLMIS-1987 - Getting issue details... STATUS

  • Discussion about a business case that would cause SOH be negative integer
  • MJ: We also need to discuss the example of issuing stock when SOH is at zero at the time of issue.

Josh's thoughts and questions:

  • a functional requirement here that lays out the first simple configuration: are negative SoH balances allowed as a result of adjustments or not. How, technically, will this be configured, how will this rule (aka policy) be enforced on the server-side and communicated to the client-side?
  • Longer term I think we should start thinking about:

    • I would expect that whatever an implementation wants to do, the rule(s) (or policy) is defined once and shared for both the front and back-end. We need to start defining how that rule would be shared, and what the basic parameters are:
      • is negative SoH even allowed: yes/no
      • if negative is allowed, is the user prompted before syncing: yes/no
      • how long can a negative SoH be allowed before alerts are sent (and to whom): is this a matter of hours? days? a function of the processing periods?
      • what kind of scheduler would we need to send those alerts, and how would we use it with the negative SoH rule (policy)?
    • After that I'd expect this rule to be configurable by perhaps Program, Facility, etc.
    • I would expect that within a Program, the rule (or policy) could change over time, how would that be done (Fowler has a class diagram of how the active policy is found by date - likely the date a person says they did something to stock)

Decision: bring to PC. Get decisions on the above questions. Share with team and start designing.

20 min

  OLMIS-633 - Getting issue details... STATUS

OLMIS-632 - Getting issue details... STATUS

  • What would be the permission for the read API
  • Do we need the write API for source/destination configuration

Permission discussion

  • Familiarize with RBAC
  • Security
  • Role based access control approach - user wants to create a stock event

Read API will be done first.

Questions: Should the write API support batch and individual sign in creation?

Decision: Need further discussion on the configuration of Sources/Destinations. How does a facility know who their valid sources and destinations? We should review and look into supply lines within requisitions. We know the hierarchy will be different than requisitions.

Approach: VR suggests creating the write API while doing the read API, however leave out the business logic and outline all the questions to be addressed for configuring the new facilities.

10 min

OLMIS-629 - Getting issue details... STATUS OLMIS-1440 - Getting issue details... STATUS

  • All reasons belong to the full reason list, can we merge these two stories? Yes
  • What would be the permission for the read API,
  • Do we need the write API for source/destination configuration

    Decision: create a new view right under the supervisory right type and a new view right under the general_admin right type
20 minOpen questions
  • As for an event which includes the facility type ID and program ID, do we need to check if that facility type supports that program ID?
  • Do we need to support the extensible for reason type and reason category? This request is coming from Fisheye review.

5 minNew QA onboard
  • Onboard materials for QA?
  • Any defined QA process/test process we should follow?

Shiyu Jin (Deactivated), where are we with permissions? I'm pasting in what Lakshmi put together.

In the end I'd like something similar to requisitions to be completed for Stock Management so people can clearly see what is being built https://openlmis.atlassian.net/wiki/display/OP/Requisition+Rights.






Stock management _ create




Stock management _ delete


Stock management _ view


A few points of discussion:

  • Which type of right are the above permissions? Requisitions is based off of program and facility. Admin are global rights. Please make sure to understand the different types so we are appropriately creating the stock management rights.
  • I haven’t added anything around authorizations here – the PC discussion concluded we might eventually want the ability for someone to audit/confirm a periodic physical stock count, but that none of the other movements need approvals. Since we’ve tabled that for later, I suggest we look at what the rights structure for that story would be while researching the story.
  • Ashraf had also mentioned sometimes large adjustments/stock movements needing extra information. I wonder if a “stock management_request info” right might be appropriate where the user has the right to send a message to the creator of the movement to provide additional information.  
  • I assume any rights around notifications will be handled by that Epic. 

Action items

OpenLMIS: the global initiative for powerful LMIS software