Updates for the voting tool
Part of #975
What does this MR do?
Makes the voting tool a bit more usable:
- do not show the options "Alle Betriebsverantwortlichen aus dem Bezirk / der Gruppe" and "Alle verifizierten foodsaver mit dem Stammbezirk der Abstimmung" when creating a poll in a work group
- show a confirm dialog before submitting a new poll
- remove the 'new poll'-bell when I voted in it
- make the text for the 'only store managers' scope more precise (see screenshot)
- shuffle a poll's options in the frontend to avoid a position effect
How confident are you it won't break things if deployed?
Quite sure with all changes except the shuffling. That one could cause wrong poll results and needs a lot of testing.
How to test
Steps a reviewer can take to verify that this MR does what it says it does e.g.
- Checkout branch locally
- Login as userbot
- Go to the polls page (region Göttingen -> Abstimmungen)
- Part A: "do not show the options..."
- Temporarily allow voting in working groups: remove the
$regionId == RegionIDs::VOTING_BETAcheck in
VotingPermissions:mayCreatePollso that it returns true for all groups.
- Go to a working group in Göttingen
- Open the 'new poll' form from the group's 'Abstimmungen' page
- You should see only three possible scopes
- Part B: "show a confirm dialog..."
- Create a poll and fill out the necessary fields
- Submit it -> you should see a confirm dialog
- Part C: "remove the bell...":
- Create a poll with a scope that includes foodsavers
- Login as a foodsaver (user2)
- There should be a bell that brings you to the poll -> vote in it
- The bell should be gone now
- Part D: "shuffle a poll's option...": go to any ongoing poll, e.g. one that you have created before. Reload the page several times. The options should be in a different order each time.
Screenshots (if applicable)
Confirm dialog when creating a poll:
Possible scopes in a region:
Possible scopes in a work group:
- added a test, or explain why one is not needed/possible...
- no unrelated changes
- asked someone for a code review
- set a "for:" label to indicate who will be affected by this change
- use "state:" labels to track this MR's state until it was beta tested
- added an entry to CHANGELOG.md
- add a short text that can be used in the release notes
Once your MR has been merged, you are responsible to create a testing issue in Beta Testing Repo:
- Consider writing a detailed description in German.
- Describe in a few sentences, what should be tested from a user perspective.
- Also mention different settings (e.g. different browsers, roles, ...). how this change can be tested.
- Be aware, that also non technical people should understand.
Release notes text
(A short text that will appear in the release notes and describes the change for non-technical people. Not always necessary, e.g. not for refactoring.)