Handling visibility of functionality with custom roles
Problem to solve
As new custom roles are implemented, existing functionality may become disabled which could disrupt the user's existing workflow. This presents us a couple problems to solve:
- How will the UI components be handled when factoring in a custom role?
- Which team manages editing the UI based on the role update?
- How are we prompting the user of no permissions outside the GitLab Application? (Example, IDE or CLI) Historically it has been 404s but if permissions become removed from users over time, this may cause confusion.
Examples:
- With
Read vulnerability
, the status dropdown is disabled. Should we keep this disabled with a prompt or hide it? - As a guest user, clicking on the WebIDE presents "Something was wrong"
- In the future - if a user has view access only or inversely no edit permissions, these components may get disabled or hidden.
Slack conversation: https://gitlab.slack.com/archives/CLW71KM96/p1701719705590139
Proposal
- How will the UI components be handled when factoring in a custom role? Pajamas Design System has guidance on visibility based on permissions.
Feature visibility is dependent on a user's permissions or subscription levels, and on which features they've chosen to enable.
When to hide a feature
- A feature is hidden when the user shouldn't have access to it due to a lack of permissions. Hiding the feature is recommended because the user doesn't need to be aware of the functionality, and there is no UI that would allow them to obtain access. For example, we should hide the delete branch button if the user's role does not allow deletion of branches.
When to keep a feature visible
- When the user has access to a feature but it's not currently enabled. In this scenario, a feature may be visible but disabled. When a feature is disabled, there should be an explanation for why it's disabled, or controls that allow a user to enable or request access to the feature.
- When child-level settings are enabled from a parent level. In this scenario, a feature may be disabled or replaced with a read-only equivalent. There should be text explaining that the setting is configured at the parent level.
- Avoid using a tooltip to explain why an element is disabled as keyboard users can't move focus to the trigger to reveal the message. Exposing the message in the UI is preferred. For example, instead of disabling the merge button on a merge request with outstanding approvals, the button is replaced with copy to explain the state, Merge blocked: all required approvals must be given.
- Which team manages editing the UI based on the role update?
- TBD
- How are we prompting the user of no permissions outside the GitLab Application?
- TBD
Edited by Joe Randazzo