Uploaded image for project: 'mod-permissions'
  1. mod-permissions
  2. MODPERMS-34

Permissions behavior when enabling module for tenant with already-existing permissionName in module descriptor

    XMLWordPrintable

    Details

    • Template:
      Standard Bug Write-Up Format
    • Sprint:
      CP: sprint 99
    • Story Points:
      3
    • Development Team:
      Core: Platform

      Description

      The current behavior is to silently ignore the new permission definition. This leads to the following potential issues:

      1. Different modules could define permissionSets with (for example) different subPermissions, but the same permissionName, with no way to ensure which one will take effect except for load order
      2. A module upgrade might reasonably want to create new "atomic" permissions and include them in compound permissionSets

      Note

      Assumption: we can allow overwriting permission sets by modules during install/upgrade but keep them immutable from the end-user viewpoint.

      In the scope of this ticket we will only fix the behavior in mod-permissions that ignores updates to permission sets during module install/upgrade.

      Open question: in case a user defines a mutable permission set with the same name as module-provided permission set we will override the user-created set. This problem should be addressed by scoping user created permission sets so that this problem never occurs.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                adam Adam Dickmeiss
                Reporter:
                wayne Wayne Schneider
                Votes:
                1 Vote for this issue
                Watchers:
                10 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases