2021-01-12 Meeting Notes

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-1744 - Getting issue details... STATUS

Ian W - I think we should be careful with looking at "layers" of permissions here... the underlying data structure is not as firmly structured as that.  Any permission can be a subpermission of any other permission

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