Skip to content

feat(721): Access Controls for Projects API#735

Open
rmonteseba wants to merge 1 commit into
3.0from
ng-721
Open

feat(721): Access Controls for Projects API#735
rmonteseba wants to merge 1 commit into
3.0from
ng-721

Conversation

@rmonteseba

Copy link
Copy Markdown
Collaborator

PR Summary

  • Added currentPermissions: ApplicationPermission[] to the Project DTO — previously returned by the backend but untyped/unused on the frontend.
  • Introduced a reusable permission framework: PermissionedEntity interface, PermissionService.hasPermission(permission, entity?), and a *hasPermission structural directive (defaults to hidden when data hasn't loaded yet).
  • Rule encoded in the framework: creation actions check the user's global permissions; actions on an existing entity check that entity's currentPermissions.
  • Add Project button (project list) now hidden without CREATE_PROJECTS.
  • Edit button (project info) now hidden without EDIT_PROJECTS.
  • Attachments component: upload control and per-file delete action now hidden without EDIT_PROJECTS, via new requiredPermission/entity inputs (defaults preserve old behavior when unset).
  • Team component: "add users" control now hidden and ACL level dropdown becomes read-only without MANAGE_PROJECT_ACCESS, via the same new inputs.
  • Global HTTP error interceptor now shows a friendly message on 403 responses instead of the generic server error text, as a safety net for stale UI/edge cases.
  • Framework is entity-agnostic by design — future tickets (e.g. Notebooks, Experiments) only need to add PermissionedEntity to their DTO and reuse PermissionService/*hasPermission without touching TeamComponent/AttachmentsComponent again.
  • No backend changes required, enforcement already exists server-side; this only makes the frontend permission-aware.

image(With permissions view, see non-hidden add member and edit CTAs)

image (No permissions view, see hidden add member and edit CTAs)

@rmonteseba rmonteseba self-assigned this Jul 15, 2026
/**
* Single source of truth for permission checks in the UI.
*
* Rule of thumb (confirmed across Project and Notebook permission tickets):

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the "confirmed" part, it looks alien in class documentation

selector: '[hasPermission]',
standalone: true,
})
export class HasPermissionDirective {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of a directive, but I have a doubt. If we are asked to disable the control instead of hiding it, do we have a way to do so?

Also, I'm thinking of Experiment screen. In our tables, if user doesn't have EDIT permission or experiment is read-only (when status is other than OPEN/REOPEN) we definitely cannot hide cells and have to disable them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants