-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Integrate Role and Permission Management from solidus_user_roles (solidus_core step)
#5129
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
base: main
Are you sure you want to change the base?
Integrate Role and Permission Management from solidus_user_roles (solidus_core step)
#5129
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @rainerdema! I know it's a draft but I was reading and I thought it was worth commenting. Other than that, what about moving the migration part (which seems quite complex) to a subsequent PR?
core/db/migrate/20230607100229_import_existing_permission_sets.rb
Outdated
Show resolved
Hide resolved
3bbbf0c to
81d1dee
Compare
waiting-for-dev
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @the-krg! 🙌 I left some comments. Besides, it looks like a merge commit slipped in the changeset.
| scope :display_permissions, -> { where('name LIKE ?', '%Display') } | ||
| scope :management_permissions, -> { where('name LIKE ?', '%Management') } | ||
|
|
||
| scope :custom_permissions, -> { | ||
| where.not(id: display_permissions) | ||
| .where.not(id: management_permissions) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about testing these scopes?
core/app/models/spree/role.rb
Outdated
| has_many :permission_sets, through: :role_permissions | ||
| has_many :users, through: :role_users | ||
|
|
||
| scope :non_base_roles, -> { where.not(name: ['admin']) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, should we add tests here?
| t.string :name | ||
| t.string :set |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still fail to understand why we need both name and set. Don't they represent the same information? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update:
I'm changing the set attribute to name and adding a new attribute named group (or label...? WDYT?).
namewill now take place assetwas before; (eg.:name: "Spree::PermissionSets::UserDisplay")groupwill be used for grouping the permissions; (eg.:Spree::PermissionSet.where(group: "Users")will return all permissions related toUsers);- when presenting the permissions for the user when creating a role, we'll displaying the groups with their permissions such as Edit, View or Custom.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be sure I understand, would different permission sets share the same group? If so, would it be possible to assign an individual permission set to a role instead of the whole group it belongs to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and yes.
A group may contain multiple permission sets related to one subject.
eg.:
<set 1 - group: Products, name: Spree::PermissionSets::ProductDisplay>
<set 2 - group: Products, name: Spree::PermissionSets::ProductManagement>
<set 3 - group: Products, name: Spree::PermissionSets::CustomPermission>
On the role creation page you should select only one, as stated on the layout. (Also because Management includes the Display permissions, so it's redundant to have both)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, it makes sense
fd82a50 to
8d8cbb5
Compare
This commit introduces database schema changes to extend the role and
permission management capabilities of Solidus.
These changes are derived from the solidus_user_roles gem and are
designed to provide more granular control over user roles and permissions.
Changes include:
* Create Spree Permission Sets:
Introduced a new Spree::PermissionSet table in the database.
This table will store sets of permissions, each with a name and set
identifier, that can be assigned to user roles.
* Create Spree Roles Permissions:
Introduced a new Spree::RolePermission table in the database.
This table will store the associations between roles and permission sets.
It includes foreign key references to the Spree::Role and
Spree::PermissionSet tables.
8d8cbb5 to
9348fe7
Compare
rainerdema
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! 👏 Thanks, @the-krg! ✅
core/app/models/spree/role.rb
Outdated
| has_many :permission_sets, through: :role_permissions | ||
| has_many :users, through: :role_users | ||
|
|
||
| scope :non_base_roles, -> { where.not(name: ['admin', 'default']) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about storing the reserved role names like 'admin' and 'default' in a constant? 🤔 like RESERVED_ROLES or STATIC_ROLES something like that.
This commit expands the functionality of the `Spree::Role` model to provide more granular and efficient control over user roles and permissions. * Spree::RolePermission * Spree::Role enhancements * Spree::PermissionSet These enhancements are a part of our broader initiative to improve the flexibility and extensibility of role and permission management in Solidus, adapting functionality from the `solidus_user_roles` gem.
This commit introduces a simple rake task that imports the Permission Sets to the DB, then iterates over the defined permissions on AppConfiguration to create the RolePermissions.
9348fe7 to
f4e0fd2
Compare
|
I'm putting this on hold until we figure out a few things on how it will be used in the new admin dashboard. |
|
@jarednorman I assume old and I do not know if @MadelineCollier carried this over to the new admin, so I'd close it depending on her reply |

Summary
Fixes #5105
This PR integrates role and permission management capabilities from the solidus_user_roles gem directly into Solidus, providing greater flexibility and control over user roles and permissions.
Major changes include:
Permission Sets: A newSpree::PermissionSetmodel has been added to the database schema. This model represents sets of permissions that can be assigned to roles. Each permission set has a name and a set identifier.Role Permissions: A newSpree::RolePermissionmodel has been added to the database schema. This model represents the association between roles and permission sets.Data Migration: Pull RequestThis rake task creates
Spree::PermissionSetrecords for each existing permission set subclass inSpree::PermissionSets::*, andSpree::RolePermissionrecords for each role's associated permission sets.(It is designed to work with both new installations and existing Solidus stores that have custom roles and permissions).
Backend interface: closedAdmin interface: Will only be merged intonebulab/adminbranchChecklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: