Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-1828

action-based permissions



    • New Feature
    • Status: Closed (View Workflow)
    • P3
    • Resolution: Won't Do
    • None
    • None
    • None
    • XXL < 30 days
    • Core: Platform
    • 105
    • CB: Bumping this way up so it is ranked similarly to the user-facing features that require it (see links below)
    • R4
    • R4
    • R4
    • R1
    • R4
    • R4
    • R4
    • R4
    • R2
    • R2


      Quite a few of the new permissions describe a specific action, e.g. change due date (UIU-582) or cancel a request (UIREQ-110).

      The backend APIs currently have permissions to allow a user to either edit (replace) a record or not.

      In order for specific actions to be associated with specific permissions we need to decide upon a general approach to how we model (name of permission, how is it described in the API and how we describe what action it relates to).

      3-17-2021: Since this jira has been created, the practice in the community has been more hands off with these kinds of technical decisions, with the idea being that a team with capacity can explore a requirement and propose a technical solution that could meet their needs and then be considered by other teams as requirements in their areas. This seems to be what is happening with permissions in this area, and there are explorations happening with things like permission overrides that are related to this need. Accordingly, the features that were blocked by this jira have been unblocked to make it easier to see that development on those features can and should proceed based on team and subject area priorities and capacity - enettifee

      TestRail: Results


          Issue Links



                jakub Jakub Skoczen
                marcjohnson Marc Johnson
                0 Vote for this issue
                10 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases