search

liquidvotingio / decidim-module-liquidvoting

GNU Affero General Public License v3.0
4 stars 0 forks source link

Initial integration with Decidim proposals #25

Closed jinjagit closed 3 years ago

jinjagit commented 3 years ago

Continues work on #2

Update (Oliver)

Closes https://github.com/liquidvotingio/decidim-module-liquidvoting/issues/27

jinjagit commented 3 years ago

Weirdness detected in original app/views/decidim/proposals/proposals/_vote_button.html.erb:
This conditional...

<% if component_settings.participatory_texts_enabled? && from_proposals_list %>
    <%= render partial: "decidim/proposals/proposals/participatory_texts/proposal_vote_button", locals: { proposal: proposal, from_proposals_list: true } %>
  <% else %>

If true, seems to destroy the layout of the endorse button and associated elements (+ changes button text to all caps):

weirdness I haven't yet understood why this happens (guess = bad/missing css ref.), nor what to do about it.
Current plan = ignore this problem, but include conditional anyway + investigate later. Note: thinking about it, this conditional won't be true unless 'participatory texts' are enabled, so need to do that, then check what happens, to understand it more fully.

EDIT:
docs/components/participatory_texts
Fetaures - including Participatory Texts

So, decidim/decidim-proposals/app/views/decidim/proposals/proposals/participatory_texts/_proposal_vote_button.html.erb is almost a carbon-copy of decidim-liquidvoting/app/views/decidim/proposals/proposals/_vote_button.html.erb. Thus, if the conditional is true, then almost the same partial is rendered as that which contains the conditional! This is confusing.

EDIT (27/11/20):
This is a bit clearer after pairing with Dave today. The _vote_button partial is based on a partial with the same name in decidim, and the _proposal_vote_button partial also exists in decidim and is very similar to _vote_button , but not identical... so, basically the conditional renders a slightly different vote button (confirmed with a diff) if participatory texts are enabled. Those differences are not yet fully understood: For example, we also managed to create a new process which uses 'participatory texts', but couldn't see any vote button on its proposals pages (config issues?), though the layout of the endorse buttons was no longer broken as in the image here.

oliverbarnes commented 3 years ago

No need to add WIP to the title when the PR is set to Draft. I've already edited it accordingly

jinjagit commented 3 years ago

Useful Decidim graph of proposal life-cycle:

proposal

jinjagit commented 3 years ago

Notes on Participatory Texts:

jinjagit commented 3 years ago

Args passed to decidim-core/app/helpers/decidim/action_authorization_helper.rb/action_authorized_button_to(action, *arguments, &block)...

When creating a vote: 

action: vote

*arguments: [
  "/processes/rerum-eaque/f/12/proposals/14/proposal_vote?from_proposals_list=false",
    {:resource=>#<Decidim::Proposals::Proposal id: 14, title: "Nisi quisquam.",
      body: "Ullam cumque ad. Voluptas incidunt mollitia. In om...",
      decidim_component_id: 12,
      decidim_scope_id: nil,
      created_at: "2020-10-26 16:30:37", updated_at: "2020-10-26 16:30:37",
      proposal_votes_count: 1,
      state: "accepted",
      answered_at: "2020-10-26 16:30:37",
      answer: {"ca"=>"Nihil consequatur corrupti molestiae voluptatem sunt reiciendis ut excepturi sed.",
                "en"=>"Alias quasi eos est corporis et eum quae non quisquam.",
                "es"=>"Aspernatur est ut fugit vel vel quod consequatur natus consectetur."},
      reference: "DVM-PROP-2020-10-14",
      address: nil,
      latitude: nil,
      longitude: nil,
      proposal_endorsements_count: 0,
      published_at: "2020-10-26 16:30:37",
      proposal_notes_count: 1,
      coauthorships_count: 5,
      position: 7,
      participatory_text_level: nil,
      created_in_meeting: false,
      endorsements_count: 8,
      cost: nil,
      cost_report: nil,
      execution_period: nil,
      state_published_at: "2020-10-26 16:30:37">,
      :remote=>true,
      :data=>{:disable=>true,
              :"redirect-url"=>"/processes/rerum-eaque/f/12/proposals/14"},
      :class=>"button expanded"}
]

&block: #<Proc:0x00007f2d88f07f50 /home/j/Documents/liquid/decidim-liquidvoting/app/views/decidim/proposals/proposals/_vote_button.html.erb:66>
&block params: []

When deleting a vote: 

action: vote

*arguments: [
  "/processes/rerum-eaque/f/12/proposals/14/proposal_vote?from_proposals_list=false",
  {:resource=>#<Decidim::Proposals::Proposal id: 14,
    title: "Nisi quisquam.",
    body: "Ullam cumque ad. Voluptas incidunt mollitia.
    In om...", decidim_component_id: 12,
    decidim_scope_id: nil,
    created_at: "2020-10-26 16:30:37",
    updated_at: "2020-10-26 16:30:37",
    proposal_votes_count: 2,
    state: "accepted",
    answered_at: "2020-10-26 16:30:37",
    answer: {"ca"=>"Nihil consequatur corrupti molestiae voluptatem sunt reiciendis ut excepturi sed.",
              "en"=>"Alias quasi eos est corporis et eum quae non quisquam.",
              "es"=>"Aspernatur est ut fugit vel vel quod consequatur natus consectetur."},
    reference: "DVM-PROP-2020-10-14",
    address: nil,
    latitude: nil,
    longitude: nil,
    proposal_endorsements_count: 0,
    published_at: "2020-10-26 16:30:37",
    proposal_notes_count: 1,
    coauthorships_count: 5,
    position: 7,
    participatory_text_level: nil,
    created_in_meeting: false,
    endorsements_count: 8,
    cost: nil,
    cost_report: nil,
    execution_period: nil,
    state_published_at: "2020-10-26 16:30:37">,
    :method=>:delete,
    :remote=>true,
    :data=>{:disable=>true,
            :original=>"Already supported",
            :replace=>"Withdraw support",
            :"redirect-url"=>"/processes/rerum-eaque/f/12/proposals/14"},
    :class=>"button expanded active light",
    :id=>"vote_button-14"}
]

&block: #<Proc:0x0000556ce7999450 /home/j/Documents/liquid/decidim-liquidvoting/app/views/decidim/proposals/proposals/_vote_button.html.erb:51>
&block params: []
oliverbarnes commented 3 years ago

Args passed to decidim-core/app/helpers/decidim/action_authorization_helper.rb/action_authorized_button_to(action, *arguments, &block)...

What's the story with these args? I'm a little lost here

jinjagit commented 3 years ago

These are the args that are passed to a method in decidim-core, when the original 'Support' button is clicked. I am assuming that we need to ensure all or most are still passed on when we integrate our voting button with the original 'Support' button.

jinjagit commented 3 years ago

Note on 'Support' button disappearing when clicked:

The 'Support' button disappears when clicked, but when the page is manually refreshed it has updated to the 'Already supported' state. This also happens if the button is then subsequently clicked again (returning to it's original state on manual page refresh). I think this has always been the case for the decidim-liquidvoting repo.
Removing all of our code from the _vote_button partial, so that it is exactly the same as the original in decidim/proposal, does not correct this behavior.
The intended functionality is for the button to update immediately it is clicked, without manual page refresh (confirmed by testing on meta-decidim website).

oliverbarnes commented 3 years ago

Yes, we'll need an ajax request to get there. I think this was discussed at some point - we could start with a page refresh and then implement the async request with js after that, following whatever is the latest decidim is using for these. Btw, React was dropped recently, which makes things a lot easier js-wise.

jinjagit commented 3 years ago

Ah, I see. I didn't realize that was the reason we were considering using ajax. I had mistakenly assumed it was something we had done that had broken the original button.

oliverbarnes commented 3 years ago

Renamed the PR to match the tracking issue: https://github.com/liquidvotingio/decidim-module-liquidvoting/issues/27

I'd like to merge this as soon as it's minimally solid to avoid another never-ending PR, and after that we can increment piecemeal (like with the LV state stuff, which would have been a nice discrete PR).

davefrey commented 3 years ago

👋 This PR is so too long, I propose we review, break out new issues for work we still want to do, and get it merged. The work is in a relatively consistent state, and does offer a working, coherent delegation/voting UI, overriding Decidim's proposal voting and abandoning their ProposalVote model.

To do this, I suggest we:

  1. Unlink issue #18 (don't Close it here) -- the vote part is done, delegations are working as page requests, ajax for this has been problematic - we can manage that separately on #18
  2. Make the other scope reductions I've suggested on issue #27