Module is not compatible with revisions

[chriswales95]

Using revisions with area votes breaks the reporting capability of the module.

With revisions turned on follow these steps to reproduce:

1. Create parties (if not in standard module taxonomy)
2. Create Areas (save)
3. Add candidates (save)
4. Add candidate votes (save)
5. Finalise votes (save)
6. View results in areas
7. Add spoiled papers OR amend votes (save)
8. View results in areas, observe winning party has disappeared from chart and runner-up now winner

Suggested solution:

1. We put in docs saying the module is not compatible with revisions for the time being
2. Revisit this later on for later elections

[willguv]

Can we ship this with revisions turned off @chriswales95 ?

[chriswales95]

@willguv They already are apart from the election content type. They're already turned off for the vote content type.

The issue I've found is that if they use localgov_workflows we're a bit stuck. That module turns on workflows and revisions for each new content type automatically.

We'll just need to advertise for users to not enable workflows for area votes and elections.

[finnlewis]

Even without workflows enabled, we can still replicate the problem, just by creating a new revision.

Steps to reproduce.

1. Create new localgov_drupal instance on Gitpod https://gitpod.io/#https://github.com/localgovdrupal/localgov_project

2. ddev composer require localgovdrupal/localgov_elections

3. ddev drush en localgov_elections_demo_content -y

4. View the Oxford East node at /election/general-election-july-2024/oxford-east

4. log in ddev drush uli
5. Edit /election/general-election-july-2024/oxford-east
6. Click 'Create new revision' and save

[chriswales95]

@finnlewis Yes, that's correct. I just mention workflows because this is how it happend with Bob who we were chatting in with Slack.

Revisions are the route cause.

So we need to make sure users don't use revisons but perhaps also mention workflows because that turns on revisions automatically as well.

[willguv]

Thanks so much both for getting to the bottom of this

[chriswales95]

Added a PR for making sure revisions are turned off by default for election nodes and added the issue as a known issue in our README.

I think we make a permanent fix after the election.

[finnlewis]

From debugging with @ekes , we think this might be due to the localgov_election_winner field referencing the same candidate paragraph that the candidates field references.

So we have the same paragraph referenced twice.

When creating a new revision, this creates two new revisions for that paragraph, and the wrong one is referenced in the candidates field.

[finnlewis]

I think we want to remove the localgov_election_winner reference to the candidate paragraph.

Then we can just store the id of the winning candidate on the node, rather than a full on entity reference revisions field.

Option 1:

• Create a new field in the standard way localgov_election_winner_id
• Make it an integer field.
• Store the paragraph id of the winner there for subsequent retrieveal
• Update all the places that the original localgov_election_winner field is used and load the paragraph as needed.

Option 2:

Reading here: https://www.drupal.org/docs/drupal-apis/entity-api/dynamicvirtual-field-values-using-computed-field-property-classes

• add a new field with hook_entity_base_field_info()
• Name it: localgov_election_winner_id
• Add code to store the value etc.
• Update all the places that the original localgov_election_winner field is used and load the paragraph as needed.

I would prefer to run with option 2, but I think option 1 will be quicker and follows the current pattern of having these fields defined in the field ui.

[finnlewis]

@dedavidson any thoughts on this one?

[dedavidson]

Option 2 is best as it is dynamic and won't need hooks to update a stored field.

[finnlewis]

@dedavidson thanks, I agree,... but... I then saw that most of the views have integration with the paragraphs reference field and I simply don't have time to go through all the views and refactor. We can do in time, but for now I've taken a different approach.

Suppress the creation of new revisions for the localgov_election_candidate paragraph.

See https://github.com/localgovdrupal/localgov_elections/pull/101

[finnlewis]

Keeping this open but removing the stable blocker label.

We've mitigated the issue with https://github.com/localgovdrupal/localgov_elections/pull/101

BUT we are still not compatible with revisions.