Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable needsPermission mixin for EE level permissions #4061

Closed
knolleary opened this issue Jun 21, 2024 · 2 comments · Fixed by #4320
Closed

Enable needsPermission mixin for EE level permissions #4061

knolleary opened this issue Jun 21, 2024 · 2 comments · Fixed by #4320
Assignees
Labels
area:frontend For any issues that require work in the frontend/UI bug Something isn't working size:XS - 1 Sizing estimation point
Milestone

Comments

@knolleary
Copy link
Member

Our core RBAC model is maintained in forge/lib/permissions.js. This allows it to be used by both front-end and back-end.

The front-end uses it by bundling that file into the front-end code at build time.

We also support components dynamically registering permissions. This is how all of the EE code augments the core code by registering its additional permission rules when the platform starts up and detects the EE license is enabled. This works fine for the backend, as it can access the in-memory combined list of permissions. But the front-end doesn't know about the EE permissions; as they are not 'present' at build time.

As such, we have some EE-only front-end elements that are shown to users who don't have permission to carry out their action - one example being creating Device Groups.

Whilst I like the componentisation of having the EE components dynamically register themselves, we need a solution that works for both backend and frontend.

One option would be for the front-end to load the permissions tables dynamically. It's an extra request whilst loading the app, for information that isn't going to change (unless an EE license gets applied).

The alternative is we just list the EE permissions in forge/lib/permissions.js and remove the dynamic registration. That does benefit in having all permissions recorded in one place for reference - rather than split between the core file and each EE feature component. Having thought it through whilst typing out the options, this is the option I think we should take.

@knolleary knolleary added bug Something isn't working area:frontend For any issues that require work in the frontend/UI labels Jun 21, 2024
@knolleary knolleary added this to the 2.6 milestone Jun 21, 2024
@knolleary knolleary added the size:XS - 1 Sizing estimation point label Jun 21, 2024
@knolleary knolleary modified the milestones: 2.6, 2.7 Jul 5, 2024
@Steve-Mcl
Copy link
Contributor

The alternative is we just list the EE permissions in forge/lib/permissions.js and remove the dynamic registration. That does benefit in having all permissions recorded in one place for reference - rather than split between the core file and each EE feature component. Having thought it through whilst typing out the options, this is the option I think we should take.

I am working on device group target snapshot clearing #4270 (a sub task in Improve Snapshot lifecycle handling #3622) and have hit this.

I have had to move the dynamic permissions in commit 516a7a6 but note I did not condition this with the presence of license/EE due to the current export structure of forge/lib/permissions.js. I think we will need to change how the permissions are initialised - perhaps via an init function so that EE permissions can be excluded when running CE (which will mean updating the code base in a few places where the permissions are required)

If you think we should make the EE permissions conditioned by license first, I can promote this issue and put #4270 on hold?

@knolleary
Copy link
Member Author

but note I did not condition this with the presence of license/EE due to the current export structure of forge/lib/permissions.js. I

That is fine as a workaround until we decide to fully address this issue. We shouldn't delay 4270 for it.

@joepavitt joepavitt modified the milestones: 2.7, 2.8 Aug 1, 2024
@cstns cstns self-assigned this Aug 2, 2024
@Steve-Mcl Steve-Mcl linked a pull request Aug 7, 2024 that will close this issue
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:frontend For any issues that require work in the frontend/UI bug Something isn't working size:XS - 1 Sizing estimation point
Projects
Status: Closed / Done
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants