-
-
Notifications
You must be signed in to change notification settings - Fork 392
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
User roles review #1605
User roles review #1605
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1605 +/- ##
===========================================
- Coverage 96.98% 64.54% -32.45%
===========================================
Files 499 56 -443
Lines 8534 990 -7544
===========================================
- Hits 8277 639 -7638
- Misses 257 351 +94 |
1 similar comment
Codecov Report
@@ Coverage Diff @@
## master #1605 +/- ##
===========================================
- Coverage 96.98% 64.54% -32.45%
===========================================
Files 499 56 -443
Lines 8534 990 -7544
===========================================
- Hits 8277 639 -7638
- Misses 257 351 +94 |
Codecov Report
@@ Coverage Diff @@
## master #1605 +/- ##
==========================================
- Coverage 96.98% 96.93% -0.06%
==========================================
Files 499 507 +8
Lines 8534 8549 +15
==========================================
+ Hits 8277 8287 +10
- Misses 257 262 +5 |
@beagleknight Thanks for paying off this technical debt! 馃槂 |
d2869f8
to
7c4e29f
Compare
2320b5f
to
b69ceab
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.
馃憦 馃憦 馃憦 馃憦 馃憦 馃憦 馃憦 馃憦 馃憦 馃憦
... but check my comments xDD
@@ -23,11 +21,10 @@ def initialize(user, _context) | |||
end | |||
|
|||
can [:read, :update], Decidim::Organization do |organization| | |||
organization == user.organization | |||
organization == @user.organization |
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.
@user
could be an instance method instead
@@ -36,7 +33,7 @@ def initialize(user, _context) | |||
can [:create, :index, :new, :read, :invite], User | |||
|
|||
can [:destroy], [User] do |user_to_destroy| | |||
user != user_to_destroy | |||
@user != user_to_destroy |
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.
Ditto
can :read, :admin_dashboard do | ||
participatory_processes.any? | ||
end | ||
class ParticipatoryProcessAdminUser < Decidim::Abilities::ParticipatoryProcessAdminUser |
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.
Why the name change?
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.
There's a controller level concern called ParticipatoryProcessAdmin
, so renaming reduces confusion in that regard.
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.
Then I'd go for appending Ability
at the end. User
is confusing as well!
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.
Agreed, but then we need to rename most of the ability classes.
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.
Well.. I personally dislike the User
suffix but it looks like a convention we followed in the past and I just normalised it.
We could use Ability
like: CurrentUserAbility
, EveryoneAbility
, ParticipatoryProcessAdminAbility
and so on.
Is it fine for you? @josepjaume @deivid-rodriguez
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.
Yeah, I think so. Sorry because it means a lot of renaming, but it definitely feels better.
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.
@josepjaume Done 馃挜
end | ||
|
||
can :manage, Attachment do |attachment| | ||
participatory_processes.include?(attachment.attached_to) | ||
can_manage_process?(attachment.attached_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.
This was here before, but maybe is too much of an asusmption? I believe attachments are polymorphic.
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.
Yeah, it is polymorphic. I'll add attached_to.kind_of? ParticipatoryProcess
then.
module Abilities | ||
# Defines the abilities for a collaborator user in the admin | ||
# section. Intended to be used with `cancancan`. | ||
class ParticipatoryProcessCollaboratorUser < Decidim::Abilities::ParticipatoryProcessCollaboratorUser |
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.
Why appending User
at the end of abilities? If we had to append anything, shouldn't it be Ability
?
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 believe appending User
is the current convention in the code...
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.
Read my comment above 馃槃
<% if can? :update, participatory_process %> | ||
<li <% if is_active_link?(decidim_admin.edit_participatory_process_path(participatory_process)) %> class="is-active" <% end %>> | ||
<%= aria_selected_link_to t("info", scope: "decidim.admin.menu.participatory_processes_submenu"), decidim_admin.edit_participatory_process_path(participatory_process) %> | ||
<% if can? :update, current_participatory_process %> |
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.
All this could probably be refactored into Decidim::Menu
at some point, right?
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.
Yeah, I think so!
config.abilities += ["Decidim::Admin::Abilities::AdminUser"] | ||
config.abilities += ["Decidim::Admin::Abilities::ParticipatoryProcessAdmin"] | ||
config.abilities += ["Decidim::Admin::Abilities::CollaboratorUser"] | ||
config.admin_abilities += ["Decidim::Admin::Abilities::AdminUser"] |
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.
Why not adding the whole array in a single statement?
config.admin_abilities += [
"Decidim::Admin::Abilities::AdminUser",
# ...
]
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.
It was like that before so I didn't thought about that 馃槀
|
||
# Grant access to admin panel by default. | ||
def define_abilities | ||
can :read, :admin_dashboard |
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.
Doesn't this mean every single user will end up seeing this? We probably need to check if the user has participatory_process_role.any?
.
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.
Not every single user because this is only applying for abilities who inherit this class. There is an extra check in the constructor as well:
# Define abilities if the user is not an admin and has at least one process to manage.
if not_admin? && has_manageable_processes?
define_abilities
...
end
So the ability is not defined if the user has not a manageable process by his role.
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.
Ok! I'm affraid this means we're hitting the DB each load just to check this, but it's fine. Let's see if it causes any performance degradation, hopefully not.
- French seed [\#1588](https://github.com/decidim/decidim/issues/1588) | ||
- Add administration users page in users section \(admin panel\) [\#1582](https://github.com/decidim/decidim/issues/1582) | ||
- Ugly margin under flash message [\#1550](https://github.com/decidim/decidim/issues/1550) | ||
_Added for new features._ |
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.
This sentences shouldn't be there, right?
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 thought they could be useful for the upcoming PRs as instructions. We can remove those lines when we do the next release 馃槃
@collection ||= Decidim::ParticipatoryProcessUserRole | ||
.includes(:user) | ||
.where(participatory_process: current_participatory_process) | ||
.order(:role, "decidim_users.name") |
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.
Why removing the Rectify::Query
? It felt nice to have it separate and unit tested.
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 removed it as a part of a huge clean up 馃槄 . I like these abstractions but I prefer using them when it's needed and since I managed to remove all occurrences but one I think it's better to keep it the logic in the same place.
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.
Well, this one was the only usage previously as well (apart from these duplicated collection
and process_admin_roles
methods). I still think it's nice to encapsulate the complexity of the query and have it tested. No big deal though :)
@@ -79,11 +79,11 @@ class Engine < ::Rails::Engine | |||
|
|||
initializer "decidim.inject_abilities_to_user" do |_app| | |||
Decidim.configure do |config| | |||
config.abilities << "Decidim::Abilities::EveryoneAbililty" |
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.
Abililty
LOL
* Remove user roles and add admin column * Removing dependencies between decidim-admin and other engines * Remove role? method completely * Fix rubocop issues * Fix engines DecidimAdmin dependencies * Fix rubocop issues * Order user roles by role and user name * Fix some permissions problems * [wip] fixing abilities * Add admin 'public' permissions * Fix participatory process admins abilities core/admin * Finish admin/core abilities * DRY some code * Fix constant autoload problems * Add participatory process moderator role * Fix rubocop issues * Add missing docs * Fix a few specs * Fix a few more specs * Fix some specs * Fix more specs * Fix proposals specs * Fix comments specs * Update CHANGELOG.md * Fix rubocop issue * Add feedback * Add 'Ability' suffix to all abilities classes * Remove unnecessary require * Fix renaming problems * Fix specs
* Remove user roles and add admin column * Removing dependencies between decidim-admin and other engines * Remove role? method completely * Fix rubocop issues * Fix engines DecidimAdmin dependencies * Fix rubocop issues * Order user roles by role and user name * Fix some permissions problems * [wip] fixing abilities * Add admin 'public' permissions * Fix participatory process admins abilities core/admin * Finish admin/core abilities * DRY some code * Fix constant autoload problems * Add participatory process moderator role * Fix rubocop issues * Add missing docs * Fix a few specs * Fix a few more specs * Fix some specs * Fix more specs * Fix proposals specs * Fix comments specs * Update CHANGELOG.md * Fix rubocop issue * Add feedback * Add 'Ability' suffix to all abilities classes * Remove unnecessary require * Fix renaming problems * Fix specs
馃帺 What? Why?
We started with the column
roles
for theusers
table and then we added theParticipatoryProcessUserRole
model to handle roles for a specific participatory process.I want to merge both so there will be admin users and users with certain roles for each participatory process.
馃搶 Related Issues
馃搵 Subtasks
roles
column and addadmin
columnrole?
method馃摲 Screenshots (optional)
Roles management:
Admin panel as a participatory process admin
Admin panel as a participatory process collaborator
Admin panel as a participatory process moderator (inside moderations page)
馃懟 GIF