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

Integrate Role and Permission Management from solidus_user_roles (solidus_core step) #5129

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

rainerdema
Copy link
Contributor

@rainerdema rainerdema commented Jun 7, 2023

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:

  1. Permission Sets: A new Spree::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.

  2. Role Permissions: A new Spree::RolePermission model has been added to the database schema. This model represents the association between roles and permission sets.

  3. Data Migration: Pull Request
    This rake task creates Spree::PermissionSet records for each existing permission set subclass in Spree::PermissionSets::*, and Spree::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).

bin/rails solidus:import_existing_permission_sets
  1. Backend interface: closed

  2. Admin interface: Will only be merged into nebulab/admin branch

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

The following are not always needed:

  • 📖 I have updated the README to account for my changes.
  • 📑 I have documented new code with YARD.
  • 🛣️ I have opened a PR to update the guides.
  • ✅ I have added automated tests to cover my changes.
  • 📸 I have attached screenshots to demo visual changes.

@rainerdema rainerdema added type:enhancement Proposed or newly added feature changelog:solidus_core Changes to the solidus_core gem labels Jun 7, 2023
@rainerdema rainerdema self-assigned this Jun 7, 2023
Copy link
Member

@kennyadsl kennyadsl left a 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?

@the-krg the-krg force-pushed the rainerd/incorporate-roles-management-code-into-the-core branch 3 times, most recently from 3bbbf0c to 81d1dee Compare August 22, 2023 13:43
@the-krg the-krg marked this pull request as ready for review August 29, 2023 13:46
@the-krg the-krg requested a review from a team as a code owner August 29, 2023 13:46
@the-krg the-krg self-assigned this Aug 29, 2023
Copy link
Contributor

@waiting-for-dev waiting-for-dev left a 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.

Comment on lines 10 to 16
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)
}
Copy link
Contributor

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?

has_many :users, through: :role_users

scope :non_base_roles, -> { where.not(name: ['admin']) }
Copy link
Contributor

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?

core/app/models/spree/role.rb Show resolved Hide resolved
Comment on lines 6 to 7
t.string :name
t.string :set
Copy link
Contributor

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? 🤔

Copy link
Contributor

@the-krg the-krg Aug 31, 2023

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?).

  1. name will now take place as set was before; (eg.: name: "Spree::PermissionSets::UserDisplay")
  2. group will be used for grouping the permissions; (eg.: Spree::PermissionSet.where(group: "Users") will return all permissions related to Users);
  3. 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.

Image 31-08-23 at 04 08

Copy link
Contributor

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?

Copy link
Contributor

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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, it makes sense

@the-krg the-krg force-pushed the rainerd/incorporate-roles-management-code-into-the-core branch 2 times, most recently from fd82a50 to 8d8cbb5 Compare September 4, 2023 21:47
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.
@the-krg the-krg force-pushed the rainerd/incorporate-roles-management-code-into-the-core branch from 8d8cbb5 to 9348fe7 Compare September 5, 2023 14:24
@the-krg the-krg requested a review from elia September 7, 2023 06:13
Copy link
Contributor Author

@rainerdema rainerdema left a 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! ✅

has_many :users, through: :role_users

scope :non_base_roles, -> { where.not(name: ['admin', 'default']) }
Copy link
Contributor Author

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.

rainerdema and others added 3 commits September 12, 2023 01:46
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.
@the-krg the-krg force-pushed the rainerd/incorporate-roles-management-code-into-the-core branch from 9348fe7 to f4e0fd2 Compare September 12, 2023 04:48
@elia elia added the hold On hold for a reason different from a breaking change label Sep 12, 2023
@elia
Copy link
Member

elia commented Sep 12, 2023

I'm putting this on hold until we figure out a few things on how it will be used in the new admin dashboard.

@elia elia removed their request for review January 22, 2024 11:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:solidus_core Changes to the solidus_core gem hold On hold for a reason different from a breaking change type:enhancement Proposed or newly added feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorporate roles management code into the core
5 participants