Forwarded motion: new view options

[MSoeb]

Description:
A forwarded motion should get a new view, where a participant can take a look back into the original version with additional information.

• The View should get a new group-permission
  • In the Motions group, over "Can forward motions"
  • The title should be "Can see motion origin" (e.g. can_see_origin)
  • Tooltip description: "Can see the origin from a forwarded motion"
• Only users with the permission can_see_origin can see the new slidetoggle and if activated the display of the new view
• The new view:
  • The Tab name should be the meeting name the motion was forwarded from/ the meeting you are in right now
  • The border from the forwarded motion should be in the warn colour (see Mock-up)
  • the last poll should be displayed openly, the other polls should be inside a mat-accordion or similar (if these instructions are unclear talk with @MSoeb)
  • other public information of the motion should be displayed *if public is not clear please ask) done by autoupdate
  • If the motion was forwarded as original motion plus amendments then the motion should be displayed in the diff version plus "Show all changes" is activated
  • If the motion was forwarded as a final version then the motion should be displayed in the final or editorial final version
  • The motion per default should be displayed in the diff version, you should be able to switch between the different versions though

Additionally (generally) wanted:

• The Submitter names (plus their structure levels) from amendments should be displayed behind "zugelassen" etc.

Note: This is just a suggestion for the new feature. It does not needs to look exactly like the mock-up

Please ask @MSoeb or @Elblinator if there are still questions

[bastianjoel]

We need to discuss the feature and add more details to the issue.

I think this still needs discussion on for example how to retrieve the data, when this view should be available, how to handle permissions, ...

[Elblinator]

waiting for #3527

[bastianjoel]

We are planning to deliver the data via autoupdate. With that we need to do adjustments to some very low level services in the client because this means that we are now in the situation where we have data of multiple meetings in our local model store. This complicates things with deleted data and view model lists.

Besides from that we should also do some refactoring in the motion-detail component in preparation to this feature.

[luisa-beerboom]

I took an in-detail look at what would have to be done in the autoupdate:
As far as I can see, the easiest way to do this would be to:

1. Expand the motion restriction so that
   • a user can see the motion if he has motion.can_see_origin in any meeting of any motion in motion/derived_motion_ids (if it should also work on deeper links of the forwarding chain, motion/all_derived_motion_ids will have to be used)
2. Expand the motion_state restriction so that state may also be seen by anyone who can see a linked motion

There were some models where I wasn't sure whether they are required to be visible in the portal, I'll write the requirements here, @Elblinator @MSoeb or @emanuelschuetze will have to determine what we need in these cases:

• motion_category or tag: Analog to what needs to be done for motion_state
• motion_block: non-internal blocks should also be visible to those who can see a referenced motion
• Among the other related models, I didn't consider it sensible that the user should be able to see mediafile attachments, list_of_speakers, projections or personal_notes, so I didn't look into it

Everything else necessary should be unlocked automatically via above-mentioned measures

[MSoeb]

motion_category or tag: Analog to what needs to be done for motion_state
motion_block: non-internal blocks should also be visible to those who can see a referenced motion
Among the other related models, I didn't consider it sensible that the user should be able to see mediafile attachments, list_of_speakers, projections or personal_notes, so I didn't look into it

Points 1 and 2 seem sensible to me. In my opinion, they can be implemented in this way. For point 3, I would exclude the media files and possibly the list of speakers.

Media files: A linked file could be of interest, as it could embed the motion in a context and the overall context is only conclusive with the media file. -> My suggestion here would be that, if technically possible or feasible with reasonable effort, media files can also be displayed and opened.

List of speakers: It is similar with lists of speakers. Knowing who has spoken can be helpful information. I see the difficulty here more in the UI implementation, where we would place this information. - For practical reasons, I would therefore want to avoid integration.

What do you think @emanuelschuetze ?