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.
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.jsand 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.