Refactoring and Simplication

[jankapunkt]

During the migration towards Meteor 3 I looked into nearly every bit of the code (I had to) and I found one of the main causes of the app's complexity.

Right now, users can select a unit from our blueprints (Mustervorlagen).
However, every time a user selects such a unit for their next teaching, the following process is started:

• the unit, including all it's related material and tasks (and items) are copied for this user and this user is set to become the new owner
• the user can now modify the unit as they like
• there is always a soft reference to the blueprint unit and its material
• however they can also use this unit without modification, rendering the copy and references obsolete
• starting the unit creates another instance of execution (lesson)
• Users can also create new (empty) units from scratch

What I think is flawed here is, that every time a unit is selected, everything is copied and the permissions are adjusted, increasing the complexity to the moon...

From a solely technical perspective, I'd rather simplify this process to the following decisions:

1. Execute an blueprint (Videotape-Style)

• users simply select existing units and don't jump into the editors but straight into the lesson view
• there is no copying of content or any adjustment of ownership, as the unit remains untouched

2. Create a custom unit from scratch

• users create an empty unit to their custom needs
• there is no reference to any blueprint material

3. Select a blueprint and create a new unit

• users create a new unit but select a blueprint unit to copy it and its material
• there is no reference to any blueprint material after the copying process
• users can freely modify the material and even restore material to it's blueprint state, if they need to

It would remove a lot of issues with managing copies and references in the models, as well as in the database itself.

Please let's talk about this @kadewe @ImkeMey