Skip to content
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

Entitled to vote list: false entries if vote delegation was activated #2482

Closed
MSoeb opened this issue Jun 10, 2024 · 2 comments · Fixed by #2521
Closed

Entitled to vote list: false entries if vote delegation was activated #2482

MSoeb opened this issue Jun 10, 2024 · 2 comments · Fixed by #2521
Assignees
Labels
Milestone

Comments

@MSoeb
Copy link

MSoeb commented Jun 10, 2024

Description: There is a protocol error in the list of entitled users who had previously delegated their vote. The vote delegation permission is still incorrectly displayed in the list, even if it has been deactivated in the meeting. The previously set vote delegation is saved and displayed in the list even though the user has voted for themselves.

example of wrong information:
image

Reproduction:

  1. open a meeting
  2. open settings > participants > vote delegation: enable vote delegation
  3. open participants: add the admin to the meeting. create a new user, add it to group delegates and delegate the voting right to the admin
  4. open setting > participants > vote delegation: deactivate it
  5. open elections: create an election and let the groups admin and delegates vote.
  6. let the admin and the other user now vote.
  7. open the entitled to vote list -> under the new created user should falsy be a hint that he/she is represented by the admin.

What should happen:
The entitled to vote list should correctly track, if a vote delegation was active during a vote or a poll. If the vote delegation permission is deactivated and a vote/poll is performed, the list should NEVER include a hint for vote delegations. Even if a vote delegation was set active before the vote. By deactivating the feature, it should be disabled even for the voting protocols.

@MSoeb MSoeb added the bug label Jun 10, 2024
@MSoeb MSoeb added this to the 4.2 milestone Jun 10, 2024
@rrenkert rrenkert added the needs investigation The cause for a bug is not clear enough, so it has to be investigated for some time label Jun 11, 2024
@Elblinator Elblinator transferred this issue from OpenSlides/openslides-client Jun 12, 2024
@luisa-beerboom
Copy link
Member

I had a bit of a look at this feature and found out the following:

The entitled_users_at_stop field is currently filled purely with data from the backend, which simply counts up all users that are currently, at the time of the poll stop, in any of the entitled groups. The vote_delegated_to_user_id field is always filled with the user id of whomever the user in question is currently delegating to. From what I can see, this happens without consideration for:

  • whether anyone who voted has been thrown out of those groups while the poll was running (which, I suppose, fits the name of the field)
  • whether the delegation user is actually in the meeting (i.e. has a group)
  • whether delegations are turned off
  • whether the delegation user actually voted for the user

My assessment of the entire situation would be as follows:

  • If the requirement is just to leave the field empty if delegations were turned off, then this is a rather easy backend task.
  • If the requirement is to show the represented by information if the delegatee was actually the one who voted, we will need to keep tabs on who votes in whose stead while the poll is running. This will probably have to be done in the vote service and then somehow transferred to the backend.

What is the requirement here @MSoeb ?

@luisa-beerboom
Copy link
Member

Talked with @MSoeb this is actually just about leaving the field empty if delegations are turned off

@luisa-beerboom luisa-beerboom removed the needs investigation The cause for a bug is not clear enough, so it has to be investigated for some time label Jul 1, 2024
@luisa-beerboom luisa-beerboom self-assigned this Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants