crs-tools / tracker

CRS Ticket Tracker
Apache License 2.0
18 stars 11 forks source link

Add subprojects/studios feature #243

Open saerdnaer opened 2 years ago

saerdnaer commented 2 years ago

Aktuelle Property-Vererebungshierarchie:

Wunsch-Hierarchie für dezentrale Konferenzen wie rC3:

Hmm, wobei man könnte eigentlich auch noch ein/zwei Schritte weiter gehen:

Related: https://github.com/crs-tools/tracker/issues/186

Zu klären:

Würde man dann den Fahrplan Import nur auf Sub/Studio-Projekt Ebene machen, oder auch auf Konferenz-Ebene? Falls letzteres müssen wir irgendwo die Zuordnung zwischen Raum und Subprojekt hinterlegen.

CodeFreezr commented 2 years ago

Aus Sicht eines Studios, wäre es gummigut ein Projekt zu haben, wo wir keine Angst haben müssen ein Setting für ein anderes Studio zu überschreiben. Was darüber an Abstraktionen sinnvoll wäre, wage ich nicht zu beurteilen, aber gründsätzlich klingt global -> series -> event -> studio imho vielversprechend und komplett.

Und vielleicht könnten man beim Erzeugen eines Projektes einfach ein Art "same as" ergänzen. So könnte z.b. ein neues Studio-Projekt für z.b. ccch oder r3s von einem vorherigem abgeleitet werden. Kenn ich so vom Jenkins.

Vielleicht sogar ergänzend, alternativ mit einer kleinen Liste an abstrakteren Projekt-Typ-Templates, z.b. "Tracker-Assisted Cut", "Video-Download Centric". Vermutlich gerade am Anfang sinnvoll wenn noch keine oder nur wenige Studio-Projekte vorhanden sind.

jjeising commented 2 years ago

Was genau soll das denn abdecken? Nur eine Vererbung von Properties? Nutzerrechte? Profile?

Was würde das lösen, was #186 nicht abdeckt?

Vielleicht sogar ergänzend, alternativ mit einer kleinen Liste an abstrakteren Projekt-Typ-Templates, z.b. "Tracker-Assisted Cut", "Video-Download Centric". Vermutlich gerade am Anfang sinnvoll wenn noch keine oder nur wenige Studio-Projekte vorhanden sind.

Project Templates mit Properties hatten wir tatsächlich schon mal diskutiert (und auch befürwortet), siehe #186.

CodeFreezr commented 2 years ago

Ja! #186 klingt schon sehr nach der Projekt-Typ Template Idee. Brauchen wir dann hier an dieser Stelle nicht weiter vertiefen.

Eine Unterscheidung zwischen einem Event-Projekt und Studio-Projekt ermöglicht es unterschiedliche Vorgehensweisen wie http-tracker-flow, import-tool, fuse-tracker-flow, scp, etc. pp. vor allem bei verteilten Events unter einen Hut zu bringen.

Im Endeffekt könnte dieses Ticket #243 als ein UseCase für #186 verstanden werden.

saerdnaer commented 2 years ago

Ich dachte jetzt tatsächlich primär an eine Vererbung der Properties. Beim rC3-2020 hatten wir an die 10 Projekte, wenn sich da nen Property während der Veranstaltung bzw. nach dem Initialen kopieren ändert musste man in jedes einzelne Projekt und den Wert dort anpassen. Oder man greift halt direkt via SQL auf die Postgres zu... 🙈

Nutzerrechte wären natürlich auch eine Idee, aber das wäre dann wohl eher nen eigenes Ticket, oder? Wobei man da dann vielleicht eher Richtung Gruppen gehen will die dann durch Anbindungen an einen Identity Provider mitgegeben werden.