-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
Your app needs to then require this asset in application.js as follows ``` //= require decidim/action_delegator ```
0fcb17a
to
4200f1a
Compare
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.
4200f1a
to
ecc5cbb
Compare
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 %> |
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 is the bit that worries me the most. I copied it but then added stuff for delegations on top, so we diverged a bit.
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 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
16a1de0
to
6ed5fa0
Compare
The only easy way I found to address |
6ed5fa0
to
9dd20a9
Compare
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.
9dd20a9
to
92f5f33
Compare
Monkeypatches
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
5947dbb
to
0be0503
Compare
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.
I summarized the design we agreed on at #19. Surely, other more specific issues will come out of it. |
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 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) %> |
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.
We could probably add a helper here
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, 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| %> |
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.
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 %> |
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.
and here
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'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?
.
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.
true! in any case, it would be simplified!
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.
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 %> |
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.
+helper
@@ -2,6 +2,7 @@ | |||
|
|||
require "rails" | |||
require "decidim/core" | |||
require "decidim/consultations" |
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!
Thanks for the feedback @microstudi . I created #21 to keep track of it. |
Picks the latest changes from https://github.com/coopdevs/decidim-module-action_delegator/. Namely, openpoke/decidim-module-action_delegator#15.
This implements user-facing delegations so that they can use what the admins set up using #6.
TODO
If the user is not logged in the app, it blows upI created Don't render delegations UI when not signed in #20