Find all Decidim code that calls Proposal#update_votes_count

[davefrey]

Since our module is repurposing the proposals.proposal_votes_count attribute, we need to know what Decidim code calls Proposal#update_votes_count. We update the attribute a different way, and so any code that calls this method is unexpected and will corrupt our vote count.

We shouldn't ignore the calls, nor make the method a no-op, because both can result in corrupting the count.

One known example: rake db:seed will generate ProposalVote objects, which then updates the vote count attribute with a Decidim (not Liquidvoting) value.

Any found calls need to be adapted to insure only Liquidvoting is updating the vote count.

Related also to #48

[davefrey]

Pausing this, too much WIP in the kanban, I'll reopen when we're on v0.24.0 and have the lv_state work integrated

[davefrey]

I think this is covered, and better addressed, by #90.

The one thing in this issue not quite covered by #90 is seeding vote data. Today the seed process writes ProposalVotes and sets the count in Proposal accordingly -- both of these things are incorrect in an LV instance of Decidim. (Note that before #90 we have some data corruption in that a seeded Proposal will carry a vote count corresponding to the number of ProposalVotes; after #90 there will be orphaned ProposalVotes but the count will correctly be zero, after checking the api.)

If we want someday to seed votes, we need to step up to voting via the LV api (perhaps converting seeded ProposalVote objects into LV votes).

Given #90 + leaving vote seeding for later, I'll close this one.

[oliverbarnes]

Reopening as per https://github.com/liquidvotingio/decidim-module-liquidvoting/issues/90#issuecomment-814028618

[oliverbarnes]

We're going with compiling where the calls are made through logs watched on Honeycomb.

[davefrey]

Agreed on approach...also I think we agreed this is lower priority for the moment, I'll return it to backlog