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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

User roles review #1605

Merged
merged 30 commits into from
Jul 19, 2017
Merged

User roles review #1605

merged 30 commits into from
Jul 19, 2017

Conversation

beagleknight
Copy link
Contributor

@beagleknight beagleknight commented Jul 13, 2017

馃帺 What? Why?

We started with the column roles for the users table and then we added the ParticipatoryProcessUserRole 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

  • Remove roles column and add admin column
  • Fix Decidim::User role? method
  • Fix abilities
  • Add missing doc
  • Update CHANGELOG.md
  • Fix tests

馃摲 Screenshots (optional)

Roles management:
image

Admin panel as a participatory process admin
image

Admin panel as a participatory process collaborator
image

Admin panel as a participatory process moderator (inside moderations page)
image

馃懟 GIF

@beagleknight beagleknight self-assigned this Jul 13, 2017
@ghost ghost added the in-progress label Jul 13, 2017
@codecov
Copy link

codecov bot commented Jul 13, 2017

Codecov Report

Merging #1605 into master will decrease coverage by 32.44%.
The diff coverage is n/a.

@@             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
Copy link

codecov bot commented Jul 13, 2017

Codecov Report

Merging #1605 into master will decrease coverage by 32.44%.
The diff coverage is n/a.

@@             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
Copy link

codecov bot commented Jul 13, 2017

Codecov Report

Merging #1605 into master will decrease coverage by 0.05%.
The diff coverage is 94.19%.

@@            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 beagleknight changed the title Remove user roles and add admin column User roles review Jul 13, 2017
@beagleknight beagleknight added this to the 0.5.0 milestone Jul 14, 2017
@deivid-rodriguez
Copy link
Contributor

@beagleknight Thanks for paying off this technical debt! 馃槂

Copy link
Contributor

@josepjaume josepjaume left a 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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the name change?

Copy link
Contributor

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.

Copy link
Contributor

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!

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor Author

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 %>
Copy link
Contributor

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?

Copy link
Contributor Author

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"]
Copy link
Contributor

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",
  # ...
]

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

mrcasals
mrcasals previously approved these changes Jul 18, 2017
- 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._
Copy link
Contributor

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?

Copy link
Contributor Author

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")
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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"
Copy link
Contributor

Choose a reason for hiding this comment

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

Abililty LOL

@josepjaume josepjaume merged commit 55ec1b8 into master Jul 19, 2017
@ghost ghost removed the in-review label Jul 19, 2017
@josepjaume josepjaume deleted the enhance/user-roles branch July 19, 2017 10:26
beagleknight added a commit that referenced this pull request Jul 20, 2017
* 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
leio10 pushed a commit to podemos-info/decidim that referenced this pull request Jul 26, 2017
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants