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

Delegations frontoffice prototype #15

Merged
merged 35 commits into from
Sep 21, 2020
Merged

Conversation

sauloperez
Copy link
Collaborator

@sauloperez sauloperez commented Sep 10, 2020

This implements user-facing delegations so that they can use what the admins set up using #6.

Peek 2020-09-15 11-01

TODO

  • Do not show the callout when no delegation has been selected
  • What if users change their minds and don't want to actually perform a delegation? how to go back without refreshing the page?
  • Extract JS out of the core and move it here
  • Add the necessary I18n keys
  • Do not show the "You have delegations" link when there is none
  • Render delegations link in consultations page in white
  • Render all possible vote button states in delegations modal
  • Fix delegations link right after voting
  • Show delegations link in gray for readability
  • Render delegations link when question is voted by current_user
  • Revoke delegated vote
  • Close the delegations modal and re-render to reflect new state
    If the user is not logged in the app, it blows up I created Don't render delegations UI when not signed in #20

@sauloperez sauloperez force-pushed the delegations-frontoffice branch from 0fcb17a to 4200f1a Compare September 15, 2020 07:57
This way we don't duplicate the query and we can refactor both calls at
the same time. Now we perform a `SELECT 1` instead of a `SELECT *`
followed by a loop over the resulting array.
In the consultations index page the consultation card's background image
makes it pretty hard to read the link. White text makes things a bit
better but the admin will still have to choose a rather dark image.
Apart from copying the large if/else block from
`question/_vote_button.html.erb` some bits need to be changed from the
`current_user` to `delegation.granter`. And things turn out not the be
simple.

`#allowed_to?` doesn't make it possible to only pass in a different
user. We are forced to pass in the `chain` argument as well, in which we
just copying the result we got from `#permission_class_chain`. Switching
this method's signature to use keyboard arguments or a hash of options
would solve this issue.
It mimics the regular vote button but just a bit smaller.
Regardless of their action: vote or unvote.
@sauloperez sauloperez force-pushed the delegations-frontoffice branch from 4200f1a to ecc5cbb Compare September 15, 2020 09:47
It works great with some images but when there is none, it becomes
invisible. We assume most coops won't upload any background image.
We don't want to fix it with the actual vote button either.
We need it to know which specific vote needs to be destroyed, although
Decidim destroys all author's votes anyway, but that's another topic.

</div>
</div>
<% end %>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is the bit that worries me the most. I copied it but then added stuff for delegations on top, so we diverged a bit.

Copy link
Collaborator

@microstudi microstudi left a comment

Choose a reason for hiding this comment

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

Why putting assets in vendor? aren't these assets part of the module?

And, I think we should include it in the view that are using it using <%= stylesheet_link_tag "decidim/action_delegator/delegations*" media: "all" %> style

@sauloperez sauloperez force-pushed the delegations-frontoffice branch 2 times, most recently from 16a1de0 to 6ed5fa0 Compare September 17, 2020 15:49
@sauloperez
Copy link
Collaborator Author

sauloperez commented Sep 17, 2020

The only easy way I found to address Close the delegations modal and re-render to reflect new state is to follow Decidim's approach on the regular vote button. Send an AJAX text/javascript request to a new endpoint that closes the delegations modal and rerenders it as done in https://github.com/decidim/decidim/blob/develop/decidim-consultations/app/views/decidim/consultations/question_votes/update_vote_button.js.erb.

@sauloperez sauloperez force-pushed the delegations-frontoffice branch from 6ed5fa0 to 9dd20a9 Compare September 18, 2020 08:46
sauloperez and others added 2 commits September 18, 2020 16:05
We need it to know which specific vote needs to be destroyed, although
Decidim destroys all author's votes anyway, but that's another topic.
@sauloperez sauloperez force-pushed the delegations-frontoffice branch from 9dd20a9 to 92f5f33 Compare September 18, 2020 14:07
I forgot we're in a loop when I first added this elements. As a result,
either the browser complains or the button doesn't work, or both.
This fixes the issue where right after voting, opening the
delegations modal again and the closing it, the former modal was there.

I'm assuming this is because without closing and removing it the fact
that has a listener attached, makes it stay in the DOM and so when we
render the new one that one is still there. Or something alike.

What I fail to understand is why does the reveal modal end up at the
bottom of the DOM even though we render it within the div
"question-<question_id>-vote-button", which holds the contents that we
re-render through update_vote_button.js.erb. Something that Foundation
does, I guess.
Code Climate is complaining about it
@sauloperez sauloperez force-pushed the delegations-frontoffice branch from 5947dbb to 0be0503 Compare September 21, 2020 09:32
The way to tell Ruby we need to evaluate `decidim-consultations` first
is through a require, which is much more reliable than the order in
which gems are listed in the Gemfile.

Besides, Rubocop wants them to be sorted alphabetically.
By copying the original spec file we make it easier to replace the
`class_eval` with a more reliable way to extend the commands behaviour.
@sauloperez
Copy link
Collaborator Author

I summarized the design we agreed on at #19. Surely, other more specific issues will come out of it.

@sauloperez sauloperez marked this pull request as ready for review September 21, 2020 11:25
Copy link
Collaborator

@microstudi microstudi left a comment

Choose a reason for hiding this comment

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

🚀 but we should note that we need to improve some cumbersome checks in the views, change them for helpers

@@ -0,0 +1,5 @@
<% if Decidim::ActionDelegator::Delegation.granted_to?(current_user, consultation) %>
Copy link
Collaborator

Choose a reason for hiding this comment

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

We could probably add a helper here

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah, probably a helper like #granted_to? makes sense

<div class="card card--secondary">
<div class="card__content">

<% Decidim::ActionDelegator::ConsultationDelegations.for(question.consultation, current_user).each do |delegation| %>
Copy link
Collaborator

Choose a reason for hiding this comment

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

here too

</div>
<% end %>
<% elsif signed_in? && question.consultation.active? %>
<% if allowed_to? :unvote, :question, { question: question }, [Decidim::Consultations::Permissions, Decidim::Admin::Permissions, Decidim::Permissions], delegation.granter %>
Copy link
Collaborator

Choose a reason for hiding this comment

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

and here

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not so sure about this one. IMO the mess with the permission chain should be solved by providing a new permission class of our own or similar so that we don't need to pass them here. As a result, this wouldn't diverge much from Decidim's calls to allowed_to?.

Copy link
Collaborator

Choose a reason for hiding this comment

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

true! in any case, it would be simplified!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

tracked in #24.

<%= t("questions.vote_button.already_voted", scope: "decidim") %>
</div>
<% end %>
<% elsif allowed_to? :vote, :question, { question: question }, [Decidim::Consultations::Permissions, Decidim::Admin::Permissions, Decidim::Permissions], delegation.granter %>
Copy link
Collaborator

Choose a reason for hiding this comment

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

+helper

@@ -2,6 +2,7 @@

require "rails"
require "decidim/core"
require "decidim/consultations"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice!

@sauloperez
Copy link
Collaborator Author

Thanks for the feedback @microstudi . I created #21 to keep track of it.

@sauloperez sauloperez merged commit d7a48a5 into master Sep 21, 2020
@sauloperez sauloperez deleted the delegations-frontoffice branch September 21, 2020 13:53
sauloperez added a commit to CoopCat-Confederacio-de-Cooperatives/decidim-coopcat that referenced this pull request Sep 21, 2020
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.

2 participants