2021-01-12 Meeting Notes
Date
Attendees
jackie.gottlieb@duke.edu (Deactivated)
Ann-Marie Breaux (Deactivated)
Goals
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
Permission issues with platform releases | Craig McNally | Discuss problems implementers are having regarding permissions; during platform releases and in general. Would like feedback from the implementers about the problems. AMB - developer view of permissions and her definition of permissions are different, which causes confusion. Erin - hard to tell what changes between releases, what has been deprecated, for ex. MW Chalmers - for the API hard to tell what permissions need to be added. There's a document but not sure which version it goes with. Unclear which permissions need to be assigned. Brooks - no way to test ahead of time. Craig - missing module issues are bugs, need more testing. Wants to exercise these APIs during bugfest but doesn't seem to be any test cases for them. Hoping for testing in Iris. Jacquie: agree that definitions on what each permission is meant to do is very opaque.  Then, putting together permission sets makes that even less clear. Q - where are the descriptions? In the module where the permissions themselves are defined. Where they are depends on the individual module. AMB - would be helpful to see those descriptions in the UI, and to make sure the POs and Devs for the app agree on what the language fir that description should be. And using the words "permission sets" is really confusing. What Craig just mentioned - logical permission sets - are (in my understanding) what we see as individual permissions in the Users app UI. Then those can be combined into UI permission sets can be combined into permission sets for a role. Patty, PO for User Mgmt - they've worked with the UI so that permissions are easier to assign, it it clunky now. Khalilah's team is helping but still work to be done. Maybe permissions could have a date on them, or a "new" flag ("updated" & "deprecated" were also suggested) AMB - In the Honeysuckle release notes: Q3 2020 (Honeysuckle) Release Notes#NewPermissions Erin - This is the feature to show users associated with a permission set or individual permissions:
-
UXPROD-1744Getting issue details...
STATUS
Tod - should people step away from the highly granular permissions and only work with the higher-level permission sets Maura - with every new release there's a new set of permissions that have to be downloaded and break them up and compare each to older version Brooks - should never have to touch the basic CRUD-level permissions, should be rolled up to the middle level Craig - Need a better understanding of what the POs are doing and need consistency among them AMB - I wonder if it would be good to have access to all the permission details in the User Settings. You can build UI permission sets there, but you don't see descriptions or who the permission is assigned to or when it was created/updated. Craig - would like to hear specifically what comes up during upgrades Jacquie - need to know which ones are being deprecated Tom W - Deprecated note would be helpful, but we also need to have a link to the new replacement permission. Jackie - trying to understand what they need to know to accurately create their permission sets but the names change over time. Assumed that the permission ID would remain the same but it changes by tenant so they have no constant identifier to cross-ref changes. Craig - the permission name is the unique identifier Craig - Core Platform work to address this: Migration of Static Permissions Upon Upgrade **See TL;DR section of this page for details for discussions below** AMB - what is static permission? Craig - those defined in a module descriptor, not user-defined ones (those under settings are a separate problem) Craig - added ability to rename a permission but tracks the old name. Display name may or may not change. Jacquie - how can we do an audit to make sure these changes are done correctly? Craig - will have to think about that Jackie - hope that the rate of name change would slow down Craig - a new API will allow an operator to purge inactive permissions AMB: Here's a view only page that shows the PO permissions spreadsheet. Scroll to the bottom and click the app name that you want. Usually column A is the UI permission name. Other columns show what that permission should be able to do. Permissions Documentation from Product Owners | |
Follow-up on Optimistic Locking | All | **Deferred until Jan 19** | |
Future topics | January 19 - receiving workflow demos |