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.

Sign up for GitHub

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

Jump to bottom

Send names of persons, that have voted, to the autoupdate-service #306

Open
ostcar opened this issue Jan 14, 2025 · 4 comments · May be fixed by #308
Open

Send names of persons, that have voted, to the autoupdate-service #306

ostcar opened this issue Jan 14, 2025 · 4 comments · May be fixed by #308
Assignees
@ostcar
Labels
feature
Milestone
4.3

Comments

@ostcar
Copy link
Member

ostcar commented Jan 14, 2025

Currently, we have the feature VoteCount. It tells, how many users have voted in which polls.

This has to be changed to the information, which userids have voted.

Here is the http-handler, that has either has to return a json-representation of map[int][]int. The value is either the complete list of user_ids of this poll, or all new user-ids since the last event.

Here is the service-function

It gets called once a second:

openslides-vote-service/vote/http/http.go

Lines 51 to 54 in e007cfc

ticketProvider := func() (<-chan time.Time, func()) {
ticker := time.NewTicker(time.Second)
return ticker.C, ticker.Stop
}

Here is the field in the models.yml, that has to be changed: https://github.com/OpenSlides/openslides-meta/blob/aff030454079ab470b544f7baa3ad1aa6a1b54d9/models.yml#L3227

Since the new field is a reverence to meeting_user, another field meeting_user/has_voted_poll_ids will be necessary.

There is already a field user/poll_voted_ids. This is filled by the backend, after the vote is done. They should not be mistaken.

@rrenkert How should the new fields be named?

  • vote/vote_count -> Rename to vote/live_vote_ids? vote/live_has_voted_ids?
  • Should the field reference a user or a meeting_user? I am pro meeting_user, since it will get less conflicts
  • How should the back-reference be called? meeting_user/live_has_voted_in_vote_id ?

This is the first time, we have a calculated relation field. I hope, it will not be a problem to create the back reference in the autoupdate-service?
@ostcar ostcar added the feature label Jan 14, 2025
@ostcar ostcar added this to the 4.3 milestone Jan 14, 2025
@ostcar ostcar self-assigned this Jan 14, 2025
@ostcar ostcar mentioned this issue Jan 14, 2025
Open
@rrenkert
Copy link
Member

rrenkert commented Jan 15, 2025 •
edited
Loading

@rrenkert How should the new fields be named?

  • vote/vote_count -> Rename to vote/live_vote_ids? vote/live_has_voted_ids?

Do we need the live in the name? Although it is a field that changes "live" ist can be requested after a vote has finished. I would prefer vote/has_voted_ids if there is no name clash.

  • Should the field reference a user or a meeting_user? I am pro meeting_user, since it will get less conflicts

Yes, meeting_user.

  • How should the back-reference be called? meeting_user/live_has_voted_in_vote_id ?

Same as above. I would prefer a name without live.

This is the first time, we have a calculated relation field. I hope, it will not be a problem to create the back reference in the autoupdate-service?

Hopefully not ;)

@ostcar
Copy link
Member Author

ostcar commented Jan 17, 2025

I don't see a name clash. The live is not needed. There is the field user/vote_ids that creates a relation, which vote-object belongs to the user. I think, this field should also be moved to meeting_user. But this is a different change.

I added the live prefix, because it could be strange, that the field is empty for old/closed polls.

This was referenced Jan 17, 2025
Open
Open
Open
@ostcar
Copy link
Member Author

ostcar commented Jan 17, 2025

@rrenkert I created PRs for meta, autoupdate-service and vote-service.

I made it a bit different then we discussed. The back reference was complicated. I don't think, that we need it and it will be much easier in the future, when we use postgress.

I only created a field poll/has_voted_user_ids. This is not a reference, but a list of user_ids. This has the disadvantage, that it returns all user ids and not only the user ids of users, that the request user can see. But maybe, this is a good thing when you want to get the number of all users, that have voted.

I used user_ids and not meeting_user_ids, because that is, what the vote-service is saving. If we want to change this, it would be clearer to update the vote-service to work with meeting_user_ids instead of user_ids.

Is this ok for you?

@ostcar ostcar linked a pull request Jan 18, 2025 that will close this issue
Change vote_count to all_voted_ids #308
Open
@rrenkert
Copy link
Member

@rrenkert I created PRs for meta, autoupdate-service and vote-service.
Is this ok for you?

In short: Yes, its ok for me! I see the points you mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ostcar ostcar

Labels
feature
Projects
None yet
Milestone
4.3
Development

Successfully merging a pull request may close this issue.

Change vote_count to all_voted_ids ostcar/openslides-vote-service
2 participants
@ostcar @rrenkert