Date

17 Oct 2017

7am PST / 4pm CEST

Meeting Link

Toll: +1-415-655-0001

Number: 199 948 686

Time	Item	Who
5m	Review agenda and discussion items	Nick Reid (Deactivated)
15m	Concurrency Update	Sebastian Brudziński
10m	UI Long term vision	Nick Reid (Deactivated)
10m	UI Architecture	Nick Reid (Deactivated)
5m	JSON Resource Representations	Chongsun Ahn (Unlicensed)

Add a new field into status changes - add previous status change - chaining essentially
Status changes would link to a status comment
Add unique constraint to reasons in requisition adjustments
- UI change would be needed as it allows a user to add multiple reasons for a single item

When do we need these changes? For 3.2.1

Questions:

Why do we have a different table in requisition adjustments, rather than using stock management?

Note: Should check requirements for stock management adjustment reasons (such as physical inventory)

Remove AngularJS
- Self-contain business logic - using Pure Javascript Objects (POJOs)
- Formalize UI Architecture
ES6
- Will help writing POJOs without Angular dependency injection
Webpack
- Code bundling and faster load times
Run-time environment
- Keep configuration variables.... configurable
"True Mobile"
- Not necessarily native, but works on tablet
- Can use camera/barcode/etc
- How to deal with different requirements and documenting/maintaining these changes
  - Need to be able to test "Happy Path" across different devices
  - We want feature sets across systems to be "more alike" than not
  - Guidance on "high level" design and architecture
- Do we talk about whole application or just single workflows when building experience
  - Maintenance considerations: easier to develop many user-persona focused "apps" or one mega app that understands our RBAC?
    - frequency of updates to the app
    - Size of app
    - people with multiple hats needing more than one app on their device
    - cross-device usage / IT burden for loading apps - in the end is an IT shop just going to update a bundle of apps at the same frequency as one mega app?
  - Performance considerations
    - Would a mega-app need to cache more meta data?
    - Do most people wear multiple hats and so the device would need to download and cache all meta-data similarly to how a mega-app might work

Generally we return "expanded" in many places
- Returning "expanded" sections causes performance values
- "Expanded" endpoints might be caused by referencedata being "locked-down"
  - Need to allow referencedata to be cache-able
  - Devs should ask community how to avoid expanded definitions, when they notice they are doing it
Want to focus on "essential" and "expanded"
- Review from ISA
- HREF property is from HL7 FHIR