Clarify that our only user role is "admin" and simplify code #13047
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.
mkllnk
added
the
user facing changes
There was a problem hiding this comment.
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.
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.
|
Hey @mkllnk, Thanks for the test case outline; I've went through these, and added a few:
Created a new admin user via super admin (via /admin/users/new). Repeated the tests above. All greens 🟢 Awesome! Merging. |
|
A quick check on this one: is it really a user-facing change? Sounds like more of a technical change. Can you confirm @mkllnk ? |
The change is only visible to super-admin. You see only one option for the role there. So I guess that we don't call that a user-facing change, you are right. |
mkllnk
added
technical changes only
Ah, got it. It was not clear to me, that this PR had any impact on the UI. Thanks! |
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.adminto 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:resetandofn: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