Anlegen von Kind-Vorgängen in unterschiedlichen Projekten

[andre-hohmann]

In Kitodo.Production 3 ist es zur Zeit nicht möglich, Kind-Vorgänge eines mehrbändigen Werkes in unterschiedlichen Projekten anzulegen. Vergleiche:

• Subordinate processes cannot be linked to superordinate process in another project #5626

Allerdings ist es möglich, dass:

• während der Migration zu Kitodo.Production 3 die Kind-Vorgänge eines mehrbändigen Werks aus unterschiedlichen Projekten unter einer Überordnung zusammengeführt werden - vergleiche:
  • Migration of serial publications: creation of duplicates #4608
• nach dem Anlegen der Kind-Vorgänge das Projekt in den Vorgangseigenschaften geändert werden kann und die Verknüpfung zu der Überordnung in einem anderen Projekt erhalten bleibt.

Somit ist es funktional möglich, dass Kind-Vorgänge einer Überordnung in unterschiedlichen Projekten angelegt werden können. Es stellt sich die Frage, aus welchen Gründen die Funktion beim Anlegen der Kind-Vorgänge nicht verfügbar ist.

Für die SLUB Dresden ist es sehr wichtig, dass die Kind-Vorgänge einer Überordnung in unterschiedlichen Projekten angelegt werden können. Es soll vermieden werden, dass mehrere Vorgänge einer Überordnung angelegt und gepflegt werden müssen.
Dies sollte unbedingt ohne zusätzliche Aufwände (nachträgliche Anpassung des Projekts in den Kind-Vorgängen, ...) möglich sein.

Um eine angemessene Lösung für #5626 zu finden, sollten die folgende Fragen beantwortet werden.

1. Aus welchen Gründen wird die Projektzugehörigkeit der Überordnungen beim Anlegen der Kind-Vorgänge geprüft?
2. Ist die Prüfung der Projektzugehörigkeit zu diesem Zeitpunkt notwendig?

[matthias-ronge]

Zumindest stellt sich hier eine Frage der Berechtigungen: Was ist, wenn der Elternvorgang in einem Projekt ist, das für mich als Vorgangsanlegender nicht sichtbar ist? Soll das Anlegen von Vorgängen hier unterscheiden, ob für mich als Benutzer das fremde Projekt, in dem die Überordnung enthalten ist, sichtbar ist? Wie soll sich die Anwendung verhalten, wenn der Elternvorgang einem anderen Mandanten gehört?

[andre-hohmann]

Vielen Dank für die Rückmeldung!

1 Berechtigungen Elternvorgang
Aus meiner Sicht ist eine Berücksichtigung der Berechtigung der Projekte der Elternvorgänge beim Anlegen der Vorgänge nicht notwendig. Ein Konzept wird vermutlich sehr komplex, da mehrere Möglichkeiten zur Verfügung stehen:

• Die Elternvorgänge werden immer angezeigt
• Die Elternvorgänge werden nur angezeigt, wenn die Projektberechtigung vorhanden sind (entsprechend Kindvorgänge)
• Es wird eine konfigurierbare Lösung erarbeitet, so dass jede Einrichtung die Anzeige der Elternvorgänge bestimmen kann
• ...

Ich vermute, dass dies in der Praxis selten notwendig sein wird. Davon ausgehend, dass die Elternvorgänge nur mit entsprechender Projektberechtigung sichtbar und bearbeitbar sind, stehen aus meiner Sicht folgende Anwendungsfälle zur Verfügung:

• Die Elternvorgänge werden beim Anlegen der Vorgänge nicht bearbeitet, so dass keine Berechtigungen notwendig sind.
• Wenn die Elternvorgänge beim Anlegen der Vorgänge bearbeitet werden (Hinzufügen von Kollektionen, Bemerkungen, ...), müssen die Bearbeiter und Bearbeiterinnen die notwendigen Projekt-Berechtigungen erhalten oder es muss eine Person bestimmt werden, die die Bearbeitung am Elternvorgang durchführt.
  In der SLUB Dresden besitzen die Bearbeiter und Bearbeiterinnen, die Vorgänge anlegen, auch recht weitreichende Projektberechtigungen. Vermutlich stehen auch in anderen Einrichtungen nicht ausreichend viele Bearbeiter und Bearbeiterinnen zur Verfügung, als dass die Projektberechtigungen sehr granular angewendet werden könnten.

Wenn jedoch andere Anwendungsfälle bestehen, können diese gerne beschrieben werden. Es sollen alle Fälle berücksichtigt werden, aber es sollte auch eingehend geprüft werden, ob alternative Abläufe oder Konfigurationen angewendet werden können.

2 Mandant
Vorgänge in anderen Mandanten sollten getrennt bleiben. Aus meiner Sicht werden Mandanten angewendet, weil sich die Vorgänge sehr stark unterscheiden, oder weil die Vorgänge von/für andere Einrichtungen erstellt werden. Ich gehe daher davon aus, dass andere Mandanten auch über eigene Regelsätze verfügen und somit die Trennung der Elternvorgänge darüber erfolgt.

In diesen Fällen sollten eigene Elternvorgänge erzeugt werden, da diese unter Umständen auch in anderen Präsentationen angezeigt werden. Es sollte ebenfalls berücksichtigt werden, dass in K10plus bei mehrbändigen Werken je Einrichtung eine eigene Überordnung mit eigener PPN erstellt wird. So wird in der Regel immer ein eigener Vorgang für die Überordnung erstellt - allerdings muss dies nicht auf alle Quellsysteme (Kataloge) zutreffen.

[andre-hohmann]

Hier noch eine Ergänzung. Es bestehen natürlich weitere Lösungsansätze, wie zum Beispiel:

1. Elternvorgänge werden keinem Projekt zugewiesen und sind somit allen zugänglich
2. Elternvorgänge werden Projekten zugeordnet, unterliegen jedoch nicht den Projektbeschränkungen

Lösungsansatz 1 führt jedoch zu dem Nachteil, dass beim Anlegen der Kindvorgänge von Zeitschriften, Zeitungen, ... jeweils das Projekt bestimmt werden muss, dem der Kindvorgang zugewiesen wird.
Lösungsansatz 2 klingt einfach, ist jedoch vermutlich aus technischer Sicht anspruchsvoll.

Mir geht es jedoch darum, dass in Kitodo.Production die Erstellung der Elternvorgänge und die Zuweisung der jeweiligen Kindvorgänge nicht von der Organisation der internen Projekten abhängt. Beziehungsweise will ich gerne wissen, weshalb dies notwendig ist.

[solth]

@andre-hohmann danke für diese alternativen Vorschläge. Ich vermute, dass beide technisch nicht wirklich gut umgesetzt werden können, da wir hierfür ein formelle Unterscheidung zwischen regulären Vorgängen und potentiellen Elternvorgängen einführen müssten. Das würde vermutlich einen sehr großen Aufwand zum Umbau des Systems erfordern, bei gleichzeitig überschaubarem Nutzen.

Wie in #5626 (comment) beschrieben würde ich daher eher für folgendes Vorgehen plädieren:

• Sowohl beim automatischen als auch beim manuellen Verlinken von Eltern-Vorgängen während des hierarchischem Imports sollte die Filterung nach Vorgängen im gleichen Projekt entfernt werden
• die Filterung nach Mandant sowie Projekten, auf welche der Nutzer Zugriff hat, sollte bestehen bleiben
• beim manuellen Verlinken (im Tab "Titelsatzverknüpfung") werden potentielle Elternvorgänge in nicht zugänglichen Projekten (e.g. Projekte, die dem Benutzer nicht explizit zugewiesen sind) angezeigt, aber mit entsprechendem Hinweis deaktiviert/nicht auswählbar gemacht; der Nutzer kann darauf hin die Vorgangserstellung abbrechen um die notwendigen Projektzuweisungen anzupassen, bevor er den neuen Vorgang erneut anlegt und dann erfolgreich verlinkt
• beim automatischen Verlinken (während des hierarchischem Imports) wird dem Benutzer eine Warnmeldung angezeigt, wenn ein passender Elternvorgang bereits im System ist, der Nutzer aufgrund der erwähnten fehlenden Projektzuordnungen jedoch keinen Zugriff darauf hat; er kann bei diesem Warnhinweis dann entscheiden, ob er den Import abbricht und die Projektzuordnungen anpasst (oder vom Adminitrator anpassen lässt) oder wissentlich ein Vorgangsduplikat als Elternvorgang im aktuellen Projekt anlegt

[matthias-ronge]

Ich vermute, dass beide technisch nicht wirklich gut umgesetzt werden können, da wir hierfür ein formelle Unterscheidung zwischen regulären Vorgängen und potentiellen Elternvorgängen einführen müssten.

Kann man davon ausgehen, dass der Elternvorgang bei einer projektübergreifenden Verknüpfung immer schon mindestens einen Kindvorgang hat? Dann wäre die Erkennung vergleichsweise einfacher. Oder wird es Fälle geben, in denen die „leere“ Überordnung in einem Projekt liegt und die Kinder alle nicht in demselben Projekt. Das kommt mir irgendwie komisch vor.

[andre-hohmann]

@matthias-ronge: Das ist nur schwer abschließend zu beantworten, da mehrere Faktoren berücksichtigt werden müsse, wie zum Beispiel:

1. Unterschiedliche Dokumenttypen - Zeitschrift, Zeitung, Mehrbändiges Werk, Bestand (Kalliope), ... : Diese Diskussion bezieht sich hauptsächlich auf Mehrbändiges Werk, Bestand (Kalliope), also Hierarchien, deren Kind-Vorgänge über einen eigenen externen Identifier verfügen, mit dem die Metadaten importiert werden. Für Zeitschriften und Zeitungen bestehen Anforderungen, die bisher nicht berücksichtigt wurden.
2. Unterschiedliche Abläufe in den Einrichtungen: Wird zuerst der Eltern-Vorgang angelegt und dann die Kind-Vorgänge? Vermutlich sind die Abläufe ähnlich, aber ich bin doch häufig erstaunt darüber, wie unterschiedlich mit Kitodo gearbeitet wird.

Ich gehe bei den Dokumenttypen Mehrbändiges Werk, Bestand (Kalliope) auch nicht davon aus, dass der Eltern-Vorgang in einem Projekt und alle Kind-Vorgänge in anderen Projekten angelegt werden. In der SLUB Dresden wird der Elternvorgang in dem Projekt angelegt, in dem der erste Kind-Vorgang angelegt wird.
Häufig werden in diesem Projekt auch die weiteren Kind-Vorgänge angelegt. Im Rahmen des Landesdigitalisierungsprogramms, werden jedoch Kitodo-Projekte für die unterschiedlichen Dienstleister erstellt, was immer häufiger dazu führt, dass die Kind-Vorgänge in unterschiedlichen Projekten angelegt werden. Die Projekte werden in der SLUB Dresden aus organisatorischen (Zugriffe, Statistik, Import-Konfiguration, ...) Gründen erstellt, so dass projektübergreifende Kind-Vorgänge nicht ungewöhnlich sind.

Bezüglich Zeitschriften und Zeitungen wird zwar immer der Eltern-Vorgang zuerst angelegt, aber ich gehe davon aus, dass zumindest der erste Kind-Vorgang anschließend angelegt wird. Für mich ergibt es ansonsten auch keinen Sinn.

Durch @solth Vorschlag, das Problem über Berechtigungen zu lösen, sind meine Vorschläge vermutlich obsolet.

[andre-hohmann]

Die Diskussion wird als beantwortet gekennzeichnet, weil ausreichend genug Fragen beantwortet wurden, um einen Pull Request zu erstellen.

Die fachliche Diskussion wurde auch in dem zugehörigen Issue geführt:

• Subordinate processes cannot be linked to superordinate process in another project #5626

Das Ergebnis mündete in dem Pull Request von @BartChris:

• Allow linking of processes to parents in different project #5663

[andre-hohmann]

@solth : Vielen Dank für das Feedback! Ich habe die Diskussion wieder geöffnet.

Aus meiner Sicht sollten wir folgende Beschränkungen zur Bearbeitung von Vorgängen unterscheiden:

1. Beschränkung zur Bearbeitung der Metadaten, Eigenschaften, ...
2. Beschränkung zum Verlinken von Vorgängen

Hinsichtlich 1 stimme ich zu, dass die Beschränkungen nicht aufgeweicht werden sollten.
Hinsichtlich 2 kann aus meiner Sicht auch ohne Projektberechtigung des Nutzers beim Anlegen die Verlinkung zwischen den Vorgängen erstellt werden.

Dein Vorschlag ist natürlich elegant, aber aus folgenden Gründen bin ich nicht davon nicht vollständig überzeugt.

1. Eine Umsetzung ist unsicher und wir benötigen relativ rasch eine Lösung, um dublette Überordnungen zu vermeiden.
2. Während des Anlegens von Vorgängen herauszufinden, dass der Vorgang nicht verlinkt werden kann und die notwendigen Projektberechtigung zu beantragen, ist für die AnwenderInnen vermutlich kein positives Erlebnis. Zudem ist das Verfahren recht aufwändig.
3. Um das Verfahren zu vermeiden, würden in der SLUB Dresden die KollegInnen, die die Vorgänge anlegen, vermutlich die Berechtigung für alle Projekte erhalten. Dies führt jedoch auch zu den Berechtigungen für die Bearbeitung der Metadaten, Eigenschaften, ... der Vorgänge in allen Projekten. Das höhlt aus meiner Sicht das Konzept der Berechtigungen/Beschränkungen noch mehr aus.
4. Wenn in der Überordnung nur der Link zu dem untergeordneten Vorgang eingetragen wird, ist aus meiner Sicht keine Projektberechtigung des Anwenders für die Überordnung notwendig.

Mir ist bewusst, dass ich mich von pragmatischen Argumenten leiten lasse, aber mir kommt es jetzt vor allem darauf an, dass wir Kitodo.Production 3 einführen und die KollegInnen gut damit arbeiten können.

[solth]

@andre-hohmann danke für die schnelle Antwort!

• Eine Umsetzung ist unsicher und wir benötigen relativ rasch eine Lösung, um dublette Überordnungen zu vermeiden.

Das verstehe ich. Wie wäre es, wenn wir hier iterativ vorgehen? Zunächst wird die strikte Filterung nach Elternvorgängen im gleichen Projekt entfernt, da dieser Part unstrittig ist und bereits das Hauptanliegen der SLUB erfüllen sollte, nämlich doppelt angelegte Elternvorgänge auszuschließen. Anschließend können weitere Ausbauschritte vorgenommen werden, aber ihr könntet prinzipiell schonmal damit arbeiten.

• Während des Anlegens von Vorgängen herauszufinden, dass der Vorgang nicht verlinkt werden kann und die notwendigen Projektberechtigung zu beantragen, ist für die AnwenderInnen vermutlich kein positives Erlebnis. Zudem ist das Verfahren recht aufwändig.

Wenn die Projektkonfiguration korrekt ist - dies liegt meiner Meinung nach in der Verantwortung des Projektadministrators - werden diese Erlebnisse für Benutzer nicht eintreten. Wenn die Konfiguration nicht korrekt ist, sollte das System auch darauf hinweisen - aus meiner Sicht sogar ein Mehrgewinn gegenüber intransparentem Aushebeln der Zugriffsregeln im Hintergrund.

• Um das Verfahren zu vermeiden, würden in der SLUB Dresden die KollegInnen, die die Vorgänge anlegen, vermutlich die Berechtigung für alle Projekte erhalten. Dies führt jedoch auch zu den Berechtigungen für die Bearbeitung der Metadaten, Eigenschaften, ... der Vorgänge in allen Projekten. Das höhlt aus meiner Sicht das Konzept der Berechtigungen/Beschränkungen noch mehr aus.

Das ist ein valides Argument. Das bedeutet aber eher, dass wir das Konzept noch weiter ausarbeiten müssen, als die bisherigen Filterregeln zu umgehen.

• Wenn in der Überordnung nur der Link zu dem untergeordneten Vorgang eingetragen wird, ist aus meiner Sicht keine Projektberechtigung des Anwenders für die Überordnung notwendig.

Hier bin ich anderer Meinung. Evtl. wäre es möglich, ein zusätzliches Recht (permission bzw. "authority") einzuführen, das explizit die Verlinkung von Vorgängen über Projektgrenzen hinweg erlaubt. Dann könnte explizit auf das Fehlen dieses Rechts hingewiesen werden, wenn ein Elternvorgang in einem separaten Projekt gefunden wurde. Der Admin könnte die Rollen zu Projektbeginn hingegen so konfigurieren, dass Benutzer nicht vollen Zugriff auf andere Projekte benötigen, um Vorgangsverlinkungen anzulegen. Wäre das evtl. eine Lösung, die für die SLUB akzeptabel wäre?

Ich möchte noch einmal deutlich machen, dass ich dein Anliegen verstehe und nicht sabotieren möchte, sondern lediglich etwas besorgt bin, dass genau an diesen Stellen später schwierig zu identifizierende Lücken im System entstehen, wenn man jetzt solche Ausnahmen einführt und sich später bei der Analyse des Systems auf bestimmte Regeln verlässt. So könnte es gut sein, dass eine Änderung an der meta.xml eines Vorgangs zurückverfolgt werden soll, dann aber Nutzer ohne explizite Projektzuordnung als potentielle Bearbeiter übersehen werden, weil Projektzuordnung eigentlich explizit der Vorgangsfilterung dient.

[andre-hohmann]

Vielen Dank für die Ausführungen! Ich habe Deine Beiträge nicht als Sabotage aufgefasst und kann das verfolgte Ziel gut nachvollziehen. Mir ist ja generell auch an einer "sauberen" Lösung gelegen - leider muss ich noch andere Aspekte berücksichtigen, die vermutlich auch in anderen Einrichtungen bekannt sind.
Ich schreibe sehr ausführlich, weil es mir wichtig ist, dass die Gründe für die zukünftige Entwicklung nachvollzogen werden können. Unter Umständen werde ich ja auf bessere interne Abläufe hingewiesen, die die Entwicklung beeinflussen - es kann ja sein, dass wir die Software nicht korrekt anwenden. Das kann nur erfolgen, wenn unsere Abläufe bekannt sind.

Deine Vorschläge "Iteratives Vorgehen" und "Zusätzliche Berechtigung" sind sehr gut. Ich gehe gleich darauf ein, will zuvor noch einen Anwendungsfall nennen, der aus meiner Sicht die Projektadministration und das Anlegen von Vorgängen negativ beeinflusst.

• Es ist möglich, dass auch Vorgängen von Überordnungen in deaktivierten Projekten verknüpft werden. Aus meiner Sicht ist es nicht sinnvoll, ein deaktiviertes Projekt erneut zu aktivieren, weil ein Vorgang zur Verknüpfung benötigt wird. Selbstverständlich kann es notwendig sein, dass der Vorgang generell bearbeitet werden muss, weil Kollektionen hinzugefügt werden. Dennoch überzeugt mich das Konzept weiterhin nicht.

Iteratives Vorgehen
Das ist ein sehr guter Vorschlag! Mit dem PR von @BartChris werden unsere Anforderungen erfüllt und wir können sehr gut damit arbeiten. Die Einführung einer erweiterten Lösung sollte erst erfolgen, wenn das Konzept vollständig erarbeitet und bestätigt wurde. Dafür bietet sich vermutlich "Zusätzliche Berechtigung" an.

Zusätzliche Berechtigung
Das scheint mir der bestmöglichste Lösungsansatz zu sein! Eine Berechtigung, die die Verlinkung eines Vorgangs mit der Überordnung zulässt, würde das Abbrechen des Anlegen von Vorgängen vermeiden, weil Projektberechtigungen vergeben werden müssen. Zudem würde dadurch auch verhindert, dass unnötigerweise Zugriff auf alle Vorgänge des jeweiligen Projekts gegeben werden muss.
Gleichzeitig werden die bestehenden Berechtigungen nicht unterlaufen.
Es muss darauf geachtet werden, dass die Berechtigung über die (Nutzer)Rollen verwaltet werden. Eine Realisierung in den Aufgaben-Eigenschaften führt zu umfangreichen Anpassungen an Vorgängen, Workflows, ... In unserer Instanz mit circa 700.000 Vorgängen führt dies zu einem Tag Ausfall durch Indexierung. Dies nur als Beispiel, dass auf alle möglichen Auswirkungen geachtet wird - insbesondere für den produktiven Betrieb.