[UX] Pattern for read-only permissions in the settings area

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

Compliance reviewers require read access to Settings data, but our current permission structure only allows this through the Owner role. This forces us to over-privilege compliance team members with full Owner permissions when they only need read-only access to Settings.

Additional persona needs:

  • Auditors who need read access to validate configuration
  • Platform team who needs read access in admin area to troubleshoot
  • Developers who need read access for settings to troubleshoot
  • Support teams to need read access to troubleshoot
  • X team to read area to get job done

Solution approach

Implement custom permissions to give read-only access to Settings area. This will follow the principle of least privilege by granting users through Custom Roles only the specific permissions they need to perform compliance reviews.

UX Review

Settings area pages shows configurations for instance, groups and projects. Custom permissions will grant read-only states for setting pages.

The current UX pajamas guides feature visibility based on permissions as:

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.

For user with read-only access granted:

  • We need to determine which components to hide, disable or convert to read-only state
  • Tooltips and help text to explaining why inputs are disabled

Pattern for read-only state

Settings comprises of the following component and use.

Settings component Used for Component state for read-only Setting
Search box Each settings section consists of toggles and checkboxes. Search box allows user to filter setting by searching for a keyword. Keep search bar to allow users to filter with keyword.
Expandable section header When navigating to a Settings Page, all sections are initially unexpanded. Keep interaction to progressively disclose sections of the settings area.
Checkboxes

Checkboxes are used in setting as a feature toggle (binary) allow, limit, show or to configure preference.

Iteration 1: Disabled

Iteration 2: Read-only state
Tables

Tables are used in a few ways:

  • As a data table to manage Service accounts, Roles and permissions
  • As an editable configuration table to manage search
  • Nested detailed page for Roles and permissions
Convert any fields to text. Remove buttons to add / edit / delete / copy entries
Primary button actions Used to save setting changes, add user input to a table, or trigger an action Remove all buttons
Field input Field inputs with help text is used to customize system behavior like timeouts, thresholds and default values. Varies from single line input and

Iteration 1: Disabled

Iteration 2: Read-only state
Toggles Used in 1 area - immediate banning, has no immediate impact as user still has to click save for changes to system Use disabled state of the component.
Radio buttons Used to select a mode and when choosing one of several options. Use disabled state of the component
Dropdown Used to select from many values - Templates section

Use disabled state of the component.

When none selected, ensure text switches to "None selected"
Links

Links into nested pages:

  • Used in Service Accounts, Integrations, Roles and Permissions

Links to documentation

Keep links into nested pages active and apply read-only states to all components in nested page.

Keep links to dcumentation
Tooltips In disabled state, user hovers component and a circle-slash icon (cancelled) Keep as is. Tooltips at every disabled component with description why permissions prohibit interaction will reduce its effectiveness.

Checklist:

  • Align on planned permissions affecting settings area
  • Validate intended behavior with customers
  • Audit and document current settings behavior
  • Establish visibility pattern for settings
    • Detail which sections should be visible / hidden for each permission, this will need to be broken down by Instance vs Group vs Project
    • Confirm when to hide vs. show-but-disable configuration options
    • Account for inherited settings
    • Collect any edge cases

Follow up:

  • #556059 - with Leave Admin mode being part of the Custom Admin Role's experience, there's an opportunity to improve its placement within the interface. We could potentially leverage the same UI design pattern used for the Leave Admin mode feature to display user's available permissions.

Next steps:

  • Align on view only state for remaining components: checkboxes, radio buttons
Edited by 🤖 GitLab Bot 🤖