[remove-template-fields] Some required changes

[jsangmeister]

• The meeting_user should bundle all information about the user in this meeting, so the following fields should also be moved to there, since they are meeting-specific: (The first 3 were previously also template fields, the latter should have been one, if we were not in the process of removing them) -> leaving them in user
  • poll_voted_ids
  • option_ids
  • vote_ids
  • poll_candidate_ids
• The test method create_user_for_meeting should be adjusted in the tests to automatically create a meeting user. Update tests which use it. (made via set_user_groups Move template field group_ids into meeting_user  #1563)
• The checks removed from the user methods (e.g. check_meeting_and_users from the user_mixin) must be added to the meeting_user.
• The fields projector/used_as_default_*_in_meeting_id should be renamed to used_as_default_projector_*_in_meeting_id or, even more verbose, used_as_default_projector_for_*_in_meeting_id to better reflect their meaning (e.g. used_as_default_polls_in_meeting_id confuses at first sight in the projector model - how can a projector be a default poll?)
• Rename meeting_user/submitted_motion_ids to motion_submitter_ids to better reflect the meaning.
• Remove redundant required: false from the models.yml - although this may also be done in Cleanup models.yml #1648

[jsangmeister]

@r-peschke any opinions?

[r-peschke]

@r-peschke any opinions?

Yes, but in the first phase we just want to remove the template fields

[jsangmeister]

Yes, but I would argue that these changes are all part of it. Let's talk about it.

[r-peschke]

• The meeting_user should bundle all information about the user in this meeting, so the following fields should also be moved to there, since they are meeting-specific: (The first 3 were previously also template fields, the latter should have been one, if we were not in the process of removing them)

  * `poll_voted_ids`
  * `option_ids`
  * `vote_ids`
  * `poll_candidate_ids`
  

This fields and also user.vote_delegated_vote_ids (renamed to user.delegated_vote_ids) should remain in user-collection, because they handle the user-object on the other side of the relation. Luisa confirmed that they are not used in the client/autoupdate-service.

* [x]  The test method `create_user_for_meeting` should be adjusted in the tests to automatically create a meeting user. Update tests which use it. (made via set_user_groups [Move template field group_ids into meeting_user  #1563](https://github.com/OpenSlides/openslides-backend/pull/1563))

* [ ]  The checks removed from the `user` methods (e.g. `check_meeting_and_users` from the `user_mixin`) must be added to the `meeting_user`.

They are, but we are using the meeting_user - methods also for the meeting-dependent part of user.create/update

* [ ]  The fields `projector/used_as_default_*_in_meeting_id` should be renamed to `used_as_default_projector_*_in_meeting_id` or, even more verbose, `used_as_default_projector_for_*_in_meeting_id` to better reflect their meaning (e.g. ``used_as_default_polls_in_meeting_id` confuses at first sight in the projector model - how can a projector be a default poll?)

* [ ]  Rename `meeting_user/submitted_motion_ids` to `motion_submitter_ids` to better reflect the meaning.

* [ ]  Remove redundant `required: false` from the `models.yml` - although this may also be done in [Cleanup `models.yml` #1648](https://github.com/OpenSlides/openslides-backend/issues/1648)

[jsangmeister]

This fields and also user.vote_delegated_vote_ids (renamed to user.delegated_vote_ids) should remain in user-collection, because they handle the user-object on the other side of the relation. Luisa confirmed that they are not used in the client/autoupdate-service.

The reverse relations are meeting-specific, so these fields belong in the meeting_user collection. All fields which were previously template fields (or should have been, in the case of poll_candidate_ids) should be moved to the meeting user. This has nothing to do with whether they are used or not.

They are, but we are using the meeting_user - methods also for the meeting-dependent part of user.create/update

Ok, but then we need to integrate the checks somewhere else. Current situation is that we removed some checks from our code without any replacement, which might lead to errors. I would need to have a look at the checks to determine which errors specificly, but that's not really the point here.