-
-
Notifications
You must be signed in to change notification settings - Fork 729
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
Clarify that our only user role is "admin" and simplify code #13047
base: master
Are you sure you want to change the base?
Conversation
We only ever check for the admin role.
We are now creating the role on demand which removes the need for seeding it as well.
We have only one role, so let's get rid of the unneeded method. Now we are in a better place to get rid of Spree::Role and replace it with a simple boolean.
The privileges of a user should never change within a request life cycle. The `spree_roles` association is very small, between 0 and 2 items are quickly searched in memory without the need of additional database queries. From memory, I've seen a lot of spree_roles queries in log files per request. This should reduce it to one.
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 for tidying this up! I've often wondered how much of the roles system we actually need, and you've demonstrated the answer: none!
I guess the reason we've never needed the roles system is because user permissions are based on their enterprise and enterprise permissions.
I can imagine perhaps one day we would want a lesser "admin" role (eg a customer support role that doesn't need to update instance config), but.. if we ever need that we can build it as needed.
Shall we replace Spree::Role.admin with an admin flag on the user?
So my answer is yes; you've already brought us halfway there 👍
@@ -60,7 +60,7 @@ def self.admin_created? | |||
|
|||
# Checks whether the specified user is a superadmin, with full control of the instance | |||
def admin? | |||
spree_roles.where(name: "admin").any? | |||
spree_roles.any? { |role| role.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.
Good solution. I would have simply reached for elvis (@admin ||=
), but this is no more queries, and ensures that if the roles are updated during a request, we get the up-to-date value.
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.
Nice cleanup 🧹
Shall we replace Spree::Role.admin with an admin flag on the user?
Yes we should, there is no point keeping extra complexity just in the off chance we might need it later.
What? Why?
Whenever I needed to make a user account admin in the console I had to type
Spree::Role.find_by(name: "admin")
. This was unnecessarily long, especially since we don't use any other roles. The database seeding was also adding the "user" role but we never use it. So here are a few steps to simplify this:Spree::Role.admin
to access that role easily.Shall we replace Spree::Role.admin with an admin flag on the user?
I would love to hear your thoughts around this. It would replace two database tables with one boolean column on spree_users. I'm sure it would have a positive effect on performance and simplify the code base further. And I think that I could do that in one or two hours.
What should we test?
Specs cover this quite well. We can't test the setup of a new instance. I tested
db:reset
andofn:sample_data
. So I would suggest a minimal check of the worst case scenario:Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates