2025.06

Migration MIR LTS 2024.06 nach 2025.06

Listet die einzelnen Schritte zur Migration von MIR LTS 2024.06 nach 2025.06 auf.

Diese Seite ist Work in Progress.
Sie wird im Rahmen der Fertigstellung des aktuellen MyCoRe-Releases weiter ergänzt!

Migrationsanleitung MIR

Hier sind weitere Schritte zur MIR-Migration gelistet, die neben der Migrationsanleitung für MyCoRe noch relevant sind.

Aktualisierung des Solr-Schemas und nachfolgende Neuindizierung der Metadaten

Damit ggf. vorhandende Abstracts in der aktuellen Sprache automatisch angezeigt werden können, müssen die folgenden CLI-Kommandos einmal ausgeführt werden.

reload solr configuration main in core main
rebuild solr metadata index in core main

Berechtigungen für Zugriffsschlüssel

Dieser Abschnitt betrifft nur Anwendungen, in denen Zugriffsschlüssel aktiv sind (MCR.ACL.AccessKey.Strategy.AllowedObjectTypes=mods, Standard in MIR).

Der Menüpunkt Zugriffsschlüssel verwalten erscheint nur noch, wenn der Nutzer das Recht manage-access-key-read oder manage-access-key-writedb auf dem Objekt hat (MIR-1443). MIR bringt dafür keine Standardregeln mit. Ohne neue Regeln sieht nur der Superuser den Menüpunkt. Am Derivat gibt es den Menüpunkt nicht mehr.

Die Regeln werden einmalig im ACL-Editor (Nutzermenü ⮕ ACL-Editor ⮕ Tab Regelzuweisungen) angelegt:

Objekt ID	Zugriffsrecht	Regel
`default_mods`	`manage-access-key-read`	administrators and editors
`default_mods`	`manage-access-key-writedb`	administrators and editors
`POOLPRIVILEGE`	`manage-access-key`	administrators only
`restapi:/access-keys`	`manage-access-key`	submitters, editors and administrators

Die Regeln administrators only, administrators and editors und submitters, editors and administrators existieren bereits aus den MIR-Standardregeln.
Der Access Key Manager arbeitet über die REST-API. Ohne die Regel auf restapi:/access-keys schlägt jeder Aufruf mit 403 fehl, auch für Administratoren. Die eigentliche Berechtigung wird anschließend über manage-access-key-{permission} auf dem Objekt geprüft, daher genügt hier eine Regel für alle Rollen, die Zugriffsschlüssel verwalten sollen. Eine Regel für manage-access-key auf restapi:/ sollte nicht angelegt werden, da sonst beide Regeln erfüllt sein müssen.
Das Recht auf POOLPRIVILEGE ermöglicht die Verwaltung über die REST-API und /access-key-manager/admin/, blendet aber den Menüpunkt am Objekt nicht ein.
Statt default_mods kann auch eine Kategorie wie mods:state:published verwendet werden.

Damit Ersteller (Submitter) auch nach der Veröffentlichung Lese-Schlüssel für ihre eigenen Objekte verwalten dürfen, muss folgendes Property gesetzt werden:

1

MCR.Access.Strategy.CreatorAnyStatePermissions=manage-access-key-read

Dies gilt in jedem Status für Nutzer mit der Rolle aus MCR.Access.Strategy.CreatorRole (in MIR submitter), die das Objekt angelegt haben. Mehrere Rechte werden mit Komma getrennt. Die Verwaltung von Schreib-Schlüsseln sollte Erstellern nicht erlaubt werden, da Dritte damit das veröffentlichte Objekt bearbeiten könnten.

Eigene Anpassungen von modsdetails-external.xsl und mir-accesskey-utils.xsl müssen überprüft werden: Links auf accesskey/manager.xml werden durch access-key-manager/{id} ersetzt, die Templates isCurrentUserAllowedToManageAccessKeys und checkRestAccessKeyPathPermission entfallen.