2017-02-27 Meeting Notes

10 min

https://openlmis.atlassian.net/browse/OLMIS-1987

@Shiyu Jin (Deactivated)

• 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

 https://openlmis.atlassian.net/browse/OLMIS-633

https://openlmis.atlassian.net/browse/OLMIS-632

@Shiyu Jin (Deactivated)

• 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

https://openlmis.atlassian.net/browse/OLMIS-629https://openlmis.atlassian.net/browse/OLMIS-1440

@Shiyu Jin (Deactivated)

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

Open questions

@Shiyu Jin (Deactivated)

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

New QA onboard

@Brandon Bowersox-Johnson

• Onboard materials for QA?

• Any defined QA process/test process we should follow?

Create

Update

Submit

Delete

View

Stock management _ create

X

X

X

Stock management _ delete

X

Stock management _ view

X