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?
We only create Stock Events when a requisition is approved
Requisition is released at final approval
Note: Should check requirements for stock management adjustment reasons (such as physical inventory)
UI Long-term Vision
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