UX/UI Analysis – RBAC MVP

UX/UI Analysis – RBAC MVP

This document summarizes the UX/UI analysis conducted for the access control MVP for Libraries in Open edX. Its purpose is to identify the key user flows that must be represented in the interface, the edge cases that require visual attention, and the open questions that will help align design, product, and technical criteria.

Identify user stories, key flows, and validations that must be represented in the interface

Key User Stories

  • View a list of users with their assigned roles and scopes.

  • Filter users by Scope and/or Role (combinable).

  • Assign one or more roles to multiple users, selecting the appropriate scope.

  • Edit a user's role and scope from the same view.

  • Revoke all of a user's roles (and remove them from the list if they no longer have access).

  • View a list of available roles and their associated permissions.

  • Manage the team of each Library directly from its panel (in-context user management UI).

Functional flows to be visually represented

  • Create, edit, delete, and publish Library content (based on permissions).

  • View and manage team members within a Library.

  • Role + Scope combined filter behavior.

  • Role assignment, editing, and revocation with clear feedback.

  • UI to display and edit role permissions (description + detailed list).

  • Blocked or disabled actions, depending on the logged-in user’s permissions.

Functional validations that must be reflected in the UI

  • Validate user permissions before allowing any action.

  • Provide clear feedback messages (success, error, warning) for every permission change.

  • Disable or hide components not available to the user.

  • Prevent redundant or duplicate actions (e.g., assigning a role already granted in a broader scope).

Prioritized List of Key Needs (for RBAC in Console)

High Priority (Must have)

  1. Clearly visualize user roles across scopes
    Admins need to understand what role a user has and where (e.g., Library A vs. Global).

  2. Assign and manage roles efficiently from the user list
    Role assignment should be accessible and require minimal steps.

  3. Allow filtering users by Role and Scope
    To support bulk actions, audits, or quick lookups.

  4. Avoid redundant role assignments
    The system should prevent or warn if a role is already granted in a broader scope.

  5. Display permissions clearly by role
    Admins must know what each role can do, ideally grouped by function (Content, Evaluation, Admin...).

Medium Priority (Should have)

  1. Enable creation of custom roles
    Starting from a template or from scratch, with clear context of where they apply.

  2. Clarify terminology and scopes in UI
    Use tags, color codes or chips to show if a role is course-level, library-level, etc.

  3. Give feedback on role changes
    Success messages, error states, and warnings when changes affect current access.

Low Priority (Nice to have for later)

  1. Compare multiple roles side by side
    Helpful for reviewing overlaps or setting up new permission schemes.

  2. Role activity logs
    Track changes made to roles or role assignments over time (for audit purposes).

Edge cases that must be addressed visually

  • Users with multiple roles in multiple scopes → UI must present them clearly and understandably.

  • User with a global role (“All Libraries”) who gets a specific scope revoked → represent as “All Libraries except [Library A]”.

  • Redundant role assignments → should be disabled in the UI.

  • Users who lose all roles → decide whether they should automatically disappear from the list or if an access history should be available.

  • Actions pending technical definition (e.g., “Import from course") → display as blocked or disabled with contextual messaging.

  • Roles assigned “in-context” within each Library → allow role management directly in the Library view without affecting other areas.

 

Ensure business logic is clearly reflected in the user experience

  • Permitted actions must clearly match the assigned permissions.

  • The distinction between “view”, “edit”, and “publish” actions must be obvious to the user.

  • Role and scope filters must behave predictably and avoid contradictory outcomes.

  • Overlapping roles must be displayed in a way that avoids confusion or ambiguity.

  • Permission and role editing should respect the admin's scope (no changes outside their authorized scopes).

  • The interface should convey clarity and confidence in every action: “Are you sure you want to remove this role?”

  • Leverage implied permission hierarchies (e.g., holding an 'edit' permission implicitly grants the corresponding 'view' permission) to simplify role definitions and ensure a logical user experience where users can perform actions on content they can access.

 

UX/UI Questions for Product & Tech Alignment

 

  1. How should a partial revocation of a global role be represented in the interface? (e.g., “All Libraries except Library A”) This behavior is mentioned in the functional spec, but it’s not clear whether users are expected to see exclusions explicitly in the UI. To define an appropriate visual pattern (e.g., exception chips, contextual messages, or tooltips), it’s important to align with the team on how this type of restriction should be interpreted and communicated through the interface.

  2. How should we handle permissions that are still TBD or not yet implemented? Should we hide them, disable them, or indicate them as “coming soon”? Some actions (like Import from Course) are pending backend implementation. From a UX perspective, we need a consistent approach to prevent confusion. For example, showing a disabled button with a tooltip such as “Feature coming soon” helps avoid user frustration and sets the right expectation.

  3. Should there be a view to consult users who no longer have active roles, but previously had access? One user story suggests the ability to manage users even after their roles have been removed. If this is in scope, the UI needs to accommodate “inactive users” with proper states, filters, or labels. If it’s out of scope, we can design around active users only.

 

Potential Conflicts and Edge Cases in Role Assignment

Conflict Type

Example

Why it’s a Problem

Suggested UX/Tech Response

Conflict Type

Example

Why it’s a Problem

Suggested UX/Tech Response

Permission Accumulation (Stacked Roles)

A user has the "Library Author" role for "Library A" and the "Library Collaborator" role for "Library B".

It's important for the admin and the user to clearly understand what permissions they have in each library due to the different assigned roles.

Clearly show the user's list of roles along with their scopes. Provide a view (potentially filtered) that shows the user's effective permissions in a specific context (e.g., when viewing a library or managing users).

Partial Revocation of a Global Role

A user has the "Library Author" role with scope "All Libraries", but access to "Library B" is revoked.

Representing this "excepted" state clearly is crucial for admin understanding.

Show the global role normally, but include a visual indicator (like a chip or a tooltip) that details the exceptions (e.g., "All Libraries (-Library B)").

Users with No Active Roles

A user had roles but they were all revoked.

Deciding whether these users should still appear in lists can affect management.

Do not show users without active roles in the main lists. Historical access management can be handled by other means if needed.