Dear dev
I made a breaking change to openlmis-auth-ui. There are currently two versions 5.0.3-SNAPSHOT and 6.0.0-SNAPSHOT
DON'T ANYONE TRY TO USE 6.0.0-SNAPSHOT (yet)
--> I'll update dependent repos when its ready
The cause for the breaking change was to make code more orthogonal and maintainable. Sections of code will be moved to openlmis-referencedata-ui because the endpoints they use are part of openlmis-referencedata.
um.... cheers?
Nick Reid | nick...@villagereach.org
Software Developer, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
Dear dev -
I would have hated myself if I didn't follow up on the changes to auth-ui
tldr; Any user right that you get from the auth-service will not have:
(a) a right ID
(b) warehouse/supervised facility codes are not available in a right
(c) there is still techDebt in authService
Overview
To speed up performance we decided to store all a user's permissions as strings. The permission strings endpoint is much faster than getting a user's rights (and the payload is smaller). From the permission strings, we can infer other information about the user and how their programs/facilities are connected (see OLMIS-3296).
This also means we can remove any direct calls to hasRight endpoints, since the browser already has that information once a user logs in. This removes some HTTP requests, which makes the app seem snappier in a high latency environment and means we can make more processes work completely offline.
A large code change that happened was removing 3 "legacy" AngularJS services/factories that were repetitive or used in a single place. They were:
- Right
- UserRightFactory --> this has been moved and simplified to UserRightsFactory (notice the addition of an "s")
Rights and right-related code is still in the codebase, we should be moving towards using "hasPermission" since its more strict (and can be searched more quickly). There are differences in what a user is returned when authorizationService hasRight & similar are used.
(a) right.id won't work anymore
Since we are parsing permission strings and using them to generate "rights" -- none of these rights have an id anymore. The right.id was used to communicate with the hasRight endpoints, but since we have that data saved locally we don't need that information anymore.
We have not done a right check like this for awhile, and I'm pretty sure I've removed any code that still uses right.id
(b) warehouse/supervised facility codes
The Right class used to contain facility codes and separated facilities depending if they were a supervisory node or a warehouse. After working with the code, I realized we never used this abstraction, and that by definition a facility with a fulfillment right can only be a warehouse.
There is only facility ids, program ids, and program codes associated with a right name -- since that is what we actually use.
(c) there is still techDebt in authService
We still have some sections of tech debt that need to be sorted out and cleaned up. It bugs me to no end that the data structure for rights that the authService exposes and loaded in from a completely different section of code.
For now we will be maintaining the current contract the authService maintains. In the future we might try to remove hasRight style methods - but we use these methods a lot, so I didn't want to try and move it.
Anyways, let me know if you have additional questions
---- nick -----
Nick Reid | nick...@villagereach.org
Software Developer, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org