Join object and block storage under ems_storage in the features tree #17512
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm trying to refactor something in the UI. For that I would like to have a way to determine if a feature related to a given model is available for a user. However, there are some inconsistencies between the features and models of storage providers.
There are three feature subtrees for storage providers:
ems_storage
ems_object_storage
ems_block_storage
When displaying a list of storage manager, the system is using the
ems_{block,object}_storage
route and I'm assuming also the feature with the same name from the RBAC tree. However, when opening a provider's summary screen, the route changes toems_storage
. This, together with the lack of separate object/block storage provider model classes is causing a lot of struggle with decorators/quadicons.To solve this problem, we had this idea with @PanSpagetka to join the two specific features under the generic one. This would solve us the problem of sub-features when deciding if we want to expose the quadicon settings to a given user for the storage providers.
I was clicking in the UI a little and it seems working, also tested our case by creating a user with access only to
ems_object_storage_view
:However, I think this is too good to be true and I am afraid I don't see the whole picture and/or I'm breaking something 😕