-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Integrate Role and Permission Management from solidus_user_roles
(solidus_core step)
#5129
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
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 :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?).
name
will now take place asset
was before; (eg.:name: "Spree::PermissionSets::UserDisplay"
)group
will 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
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 :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. |
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::PermissionSet
model 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::RolePermission
model 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::PermissionSet
records for each existing permission set subclass inSpree::PermissionSets::*
, andSpree::RolePermission
records 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/admin
branchChecklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: