Date

12 Dec 2017

7am PST / 4pm CET

Meeting Link

https://meetings.webex.com/collabs/#/meetings/detail?uuid=M0UUCAJ68OYLPMKAROOE9PJSBW-3O29&rnd=897752.12165

Toll: +1-415-655-0001

Number:  199 948 686 

Attendees

All are welcome

• Josh Zamor
• Paweł Albecki (Deactivated)
• Łukasz Lewczyński (Deactivated)
• Mateusz Kwiatkowski
• Brandon Bowersox-Johnson
• Elias Muluneh
• Nikodem Graczewski (Unlicensed)
• Sebastian Brudziński
• Mary Jo Kochendorfer (Deactivated)
• Chongsun Ahn (Unlicensed)

Goals

• Identify all the discussions occurring on the dev forum - is it still in discussion?  Does it have tickets?  Need prioritizing?  Already in progress?  Done?
• Dive deep on expanded rest pattern

Discussion items

Notes

Orderable edit

• going with versioning
• tickets:
  • Investigate and design pattern for versioned endpoints (ticket)
  • Implement versioning in orderables - write operation (ticket)
  • Go through parts of code for things which are immutable
  • update classes that use them (Requisition, ) and the REST json with a version # in it that references Orderables
• propose a cool down period (days to week)
  • to think about other places in the code that need changes
• Orderables and program Oderables for Malawi before FTAP

REST issues

• Mateusz Kwiatkowski to create 4 epics:  3 bugs, minimal representations, and swagger, put with a client ID for adjustments/phys inv in Stock Management

Multiple errors in REST

Agreed to nested fields instead of flattened fields.

Next steps:

• add nested pattern to style guide:   Paweł Albecki (Deactivated)
• change our APIs and Validators (Req and Ref data) to use these
  • make use of Spring Validator - has facilities to use nested fields (every validator would need to be refactored)
  • could try to use it first in a reference data screen: needs a complex screen - well wait for a complex enough screen Nick Reid (Deactivated)
    • Administration Screens
  • could try it in a fulfillment screen (Orderables):
  • examples in design have used requisition product grid

Skipping authorization

• taking approach where submit step is going direct to AUTHORIZED status
  • with a button that says "Submit and Authorize" (or button that says "Authorize")
• get rid of AUTHORIZED status - no technical reason to need both statuses (the state stays the same, we have an authorize and approval still).  This isn't blocking previous action item.
  • If it's IN_APPROVAL state, at least one other entity has gone through and reviewed that RnR.
  • IN_APPROVAL status added for reporting

• Sebastian Brudziński to followup on ticket for skip authorize:
• Sebastian Brudziński to followup on AUTHORIZED status:
  

Expanded REST pattern

Step by step guide:

https://groups.google.com/forum/#!topic/openlmis-dev/lvpKa1Krgec

Action Items

see inline above