h1. OPUS 4 Release Notes h2. ======================== Release 4.3.1 2013-02-21 ======================== h3. Bugfixes In diesem Release wurden einige Fehler behoben, genaueres findet sich in der Datei CHANGES.txt h2. ======================== Release 4.3.0 2012-12-20 ======================== h3. Anpassung an den PHTML-Dokumenttyp-Templates Sämtliche Dokumenttyp-Templates im Verzeichnis modules/publish/views/scripts/form wurden angepasst. Zum einen wurde ein auskommentierter Codeblock direkt unter dem OPUS4-Prolog entfernt. Außerdem wurde zur Vermeidung doppelter Übersetzungen die Zeile

title ?>

ersetzt durch

translate($this->title) ?>

Die alten Dokumenttyp-Templates funktionieren weiterhin. Wird die Änderung bezüglich der Übersetzung nicht nachgezogen, so erscheint auf der zweiten Seite des Publikationsformulars ein nicht übersetzter Titel. Die Funktionsweise der Formulare wird dadurch nicht berührt. Die Änderung wird automatisch beim Update übernommen, sofern die Dokumenttyp- Templates nicht vom Benutzer verändert wurden. Geänderte oder neu angelegte Dokumenttyp-Templates müssen manuell aktualisiert werden. Das Update-Skript wird bei geänderten Templates einen Hinweis ausgeben. h3. Änderung an der Frontdoor - index.xslt Die Datei modules/frontdoor/view/scripts/index.xslt wurde aufgeteilt, um die Übersichtlichkeit und Wartbarkeit zu verbessern. Die bisher in dieser Datei definierten XSLT-Templates wurden in mehrere Dateien verschoben, die nun im Unterverzeichnis "templates" liegen. Sofern sie eine eigene, angepasste index.xslt verwenden, können sie diese ohne Änderungen weiter verwenden. Die ausgelagerten Templates werden in diesem Fall nicht verwendet. Stellen Sie dabei sicher, dass ihre eigene Version der Datei bei einem Update nicht überschrieben wird, indem sie vor dem Update eine Sicherungskopie erstellen und diese danach wieder herstellen. Eventuelle Änderungen, die sich durch ein Update ergeben, müssen in diesem Fall von Hand eingearbeitet werden. h2. ======================== Release 4.2.2 2012-07-04 ======================== h3. URNs werden nur noch für Dokumente mit sichtbarem Volltext vergeben Die DNB lässt nur URNs für Dokumente mit Volltexten zu. Daher wurde die Vergabe von URNs auf Dokumente im Status "published" beschränkt, die per OAI sichtbare Dateien besitzen. Sichtbar per OAI sind alle Dateien, bei denen das Attribut "VisibleInOai" auf 1 gesetzt ist. Bitte stellen Sie für bereits existierende Dokumente sicher, dass Sie keine Dokumente ohne sichtbare Dateien an die DNB melden. Zu diesem Zweck haben wir ein kleines Script für Sie vorbereitet: $ opus4/scripts/ $ php opus-console.php snippets/find_urns_for_docs_without_visible_files.php h3. Paginierung in der Exportausgabe Mit dieser Version ist die Paginierung innerhalb des Exports möglich (unter Verwendung der Parameter *start* und *rows*). Bislang wurden die beiden Paginierungsparameter ignoriert (im Export waren immer alle Suchtreffer enthalten). Wird der Export durch Anhängen von '/export/xml' aus einer Suchergebnisseite angefordert, so sind nun nur noch die dort angezeigten Treffer im Exportergebnis enthalten. Will man dagegen alle Ergebnisse der Suche exportieren, so müssen die beiden Paginierungsparameter aus der URL entfernt werden. h3. Hilfedateien (FAQ-, Kontakt- und Impressumsseite) Die Hilfedateien liegen jetzt unter $BASEDIR/opus4/application/configs/help". (Siehe auch Dokumentation Kapitel 8.10 ff. und 11.4) Beim Update von existierenden Instanzen werden die Dateien automatisch verschoben. Danach wird für jede Datei nachgefragt, ob sie ersetzt werden soll. Die Konfiguration der Hilfeseite, die bisher in der Datei "$BASEDIR/opus4/modules/home/views/scripts/index/help.phtml" erfolgte, befindet sich jetzt in der Datei "$BASEDIR/opus4/application/configs/help/help.ini". Die alte Konfiguration muß manuell übertragen werden. h3. Umbenennung von benutzerspezifischen Enrichment-Feldern Mit OPUS 4.2.2 wird in der Standardauslieferung ein neues Enrichment-Feld eingeführt, das für die Migration von Dokumenten aus OPUS3 relevant sind: * InvalidVerification Damit im Rahmen eines OPUS4-Updates keine Konflikte mit identischen, vom Benutzer angelegten, Enrichment-Feldern auftreten, wird ein gleichnamiges benutzerdefiniertes Enrichment-Feld vor dem Update auf OPUS 4.2.2 umbenannt in: * TempInvalidVerification Im Falle einer Umbenennung muss die Übersetzungsressource des alten Feldes angepasst werden. Zum Beispiel muss im Falle der Umbennung von SourceTitle in TempSourceTitle in der Datei $BASEDIR/opus4/modules/default/language_custom/custom.tmx folgende Änderung vollzogen werden: ersetze ... durch ... h3. Änderungen an Solr-Indexschema Wird der Solr-Server nicht im Rahmen des Updateskripts aktualisiert (weil er z.B. auf einem anderen Server betrieben wird), dann muss das Indexschema aktualisiert werden. Dazu muss die Datei * solrconfig/schema.xml in das Konfigurationsverzeichnis der Solr-Server kopiert werden und anschließend der Index neu erstellt werden mittels: cd $BASEDIR/opus4/scripts ./SolrIndexBuilder.php h2. ======================== Release 4.2.1 2012-03-01 ======================== h3. Validierung des XML-Dumps für die Migration aus OPUS3 Ab dieser Version wird der Opus3-XML-Dump vor Beginn der Migration validiert. Treten dabei Fehler auf, bricht die Migration mit Hinweis auf Fehlerstelle und Fehlerursache ab. Wir empfehlen in diesem Fall, den Opus3-XML-Dump von Hand zu korrigieren und die Migration anschließend erneut durchzuführen. h3. Migration von Volltextdateien aus OPUS3 mit fehlerhaften Sonderzeichen Enthält der Dateiname eines Dokuments fehlerhafte Sonderzeichen, wird diese Datei mit modifizierten Dateinamen migriert: die fehlerhaften Zeichen werden aus dem Dateinamen herausgeschnitten. Wir empfehlen, die Originaldatei nach Abschluss der Migration von Hand umzubenennen und über die Administration einzufügen. Die durch die Migration umbenannte Datei kann anschließend gelöscht werden. h2. ======================== Release 4.2.0 2012-01-27 ======================== h3. Dokumentation im Tarball aufgenommen Ab dieser Version ist die aktuelle Dokumentation in deutscher Sprache im Tarball enthalten (opus_dokumentation_de.pdf). h3. Änderungen an Solr-Indexschema Wird der Solr-Server nicht im Rahmen des Updateskripts aktualisiert (weil er z.B. auf einem anderen Server betrieben wird), dann muss das Indexschema aktualisiert werden. Dazu muss die Datei * solrconfig/schema.xml in das Konfigurationsverzeichnis der Solr-Server kopiert werden und anschließend der Index neu erstellt werden mittels: cd $BASEDIR/opus4/scripts ./SolrIndexBuilder.php h3. Änderungen an der Datenbank Das Update-Script befüllt für alle Collections automatisch das Feld "oai_subset" mit dem Inhalt des Feldes "number", sofern "number" gesetzt und das Feld "oai_subset" nicht leer ist. Eventuelle manuelle Änderungen des Feldes "oai_subset" überschreibt das Update nicht. Trotzdem empfehlen wir ein Backup Ihrer OPUS4-Instanz und -Datenbank vor dem Update. Kapitel 9.7 "Sammlungen verwalten" beschreibt, welche OAI-Einstellungen die Collections besitzen und wie diese manuell geändert werden können. h3. Migration der sammlungsbasierten Schriftenreihen Die Schriftenreihen werden in OPUS 4.2.0 neu modelliert. Es gibt nun ein eigenes Modell für die Abbildung von Schriftenreihen. Der Umweg über die Sammlung mit dem Namen _series_ und das Speichern der (global gültigen) Bandnummer eines Dokuments im Feld IdentifierSerial entfällt damit ab sofort. Damit kann ein Dokument fortan mehreren Schriftenreihen zugewiesen werden. Pro Schriftenreihe muss eine Bandnummer für das Dokument für das Dokument vergeben werden. Im Rahmen des Updates werden -- nach Bestätigung durch den Benutzer -- die Einträge in der Sammlung series auf das neue Schriftenreihen-Modell migriert. Für jeden Sammlungseintrag wird eine neue Schriftenreihe angelegt. Dabei werden Name, Sichtbarkeitsstatus und Sortierung übernommen. Die einzelnen Aktionen bei der Durchführung der Migration werden im Logfile $BASEDIR/UPDATE-series.log protokolliert. Bei der Übernahme von Dokumenten, die den Sammlungseinträgen der Sammlung series zugeordneten sind, werden im Rahmen der Migration mehrere Fälle unterschieden. Fall 1: Dokument hat keinen IdentifierSerial (Bandnummer) * das Dokument wird nicht migriert -- es verbleibt am Sammlungseintrag / an den Sammlungseinträgen in der Sammlung series * es wird eine Warnung im Logfile ausgegeben (diese enthält die ID des Dokuments) * im Zuge der Nacharbeit kann das Dokument manuell in die neuen Schriftenreihen migriert werden -- dabei muss eine Bandnummer festgelegt werden Fall 2: Dokument hat mehrere IdentifierSerial * das Dokument wird nicht migriert -- es verbleibt am Sammlungseintrag / an den Sammlungseinträgen in der Sammlung series * es wird eine Warnung im Logfile ausgegeben (diese enthält die ID des Dokuments) * im Zuge der Nacharbeit kann das Dokument manuell in die neuen Schriftenreihen migriert werden -- dabei muss eine Bandnummer festgelegt werden * ggf. können nach der Übernahme die nicht mehr benötigten IdentifierSerials manuell vom Dokument entfernt werden Fall 3: Dokument hat genau einen IdentifierSerial * grundsätzlich: das Dokument wird nur dann in die neuen Schriftenreihen migriert, wenn es zu keinem Bandnummernkonflikt (d.h. bei der Zuweisung zu einer Schriftenreihe wird eine Bandnummer verwendet, die für ein bereits zugewiesenes Dokument in der Schriftenreihe genutzt wurde) kommt * für jeden Sammlungseintrag aus der Sammlung series, für den eine Verknüpfung mit dem Dokument besteht, wird die Migration in die neuen Schriftenreihen durchgeführt * tritt dabei kein Konflikt auf, so wird der IdentifierSerial als Bandnummer gesetzt und vom Dokument entfernt; ferner wird die Verknüpfung zum Sammlungseintrag nach der Übernahme in die Schriftenreihe entfernt * tritt ein Konflikt auf, so wird eine Warnung ins Logfile geschrieben (enthält ID des Dokument und ID des betroffenen Sammlungseintrags) Am Ende der Migration wird die Sammlung series auf unsichtbar gesetzt, so dass Sie für den Benutzer fortan nur noch in der Administration angezeigt wird. Das Updateskript gibt nach Beendigung eine Statistik aus. Aus dieser können * die Anzahl der aufgetretenen Konflikte * die Anzahl der migrierten Sammlungseinträge * die Anzahl der erfolgreich migrierten Dokumente entnommen werden. Sind die erforderlich Nacharbeiten nach Durchsicht der Logdatei abgeschlossen, kann die Sammlung series entfernt werden. h3. Migration von SubjectMsc bzw. SubjectDdc in die Sammlungen msc bzw. ddc In früheren Versionen konnten MSC- und DDC-Klassifikationen eines Dokuments sowohl in den Sammlungen (msc bzw. ddc) als auch in den Subject-Feldern SubjectMsc bzw. SubjectDdc gespeichert werden. Mit OPUS 4.2.0 entfällt die letztgenannte Möglichkeit. Daher müssen die Subject-Felder beim Update in die Sammlungen migriert und anschließend gelöscht werden. Die während der Migration der Subject-Felder durchgeführten Änderungen werden in der Logdatei $BASEDIR/UPDATE-subjects.log protokolliert. Folgende Schritte werden beim Update für jedes Dokument durchgeführt: * es werden alle Werte in den Feldern SubjectMsc bzw. SubjectDdc betrachtet * wenn das Dokument bereits einem Sammlungseintrag zugeordnet ist, dessen Nummer dem Wert des Subject-Feldes entspricht, dann wird das Subject-Feld entfernt * andernfalls wird das Dokument dem entsprechenden Sammlungseintrag zugewiesen und anschließend das Subject-Feld entfernt * im Rahmen des Versuchs der Zuweisung kann folgender Fehlerfall auftreten: es gibt keinen oder mehrere Sammlungseinträge mit der gegeben Nummer. In diesem Fall wird der Wert des Subject-Feldes in einem Enrichment 'MigrateSubjectDDC' bzw. 'MigrateSubjectMSC' abgelegt. Das Subject-Feld wird anschließend entfernt. Werden während des Prozesses Werte aus den Subject-Feldern in Enrichments gespeichert, so ist im Anschluss an die Ausführung des Updates eine manuelle Nacharbeit erforderlich. h3. Anpassungen im den XML-Dokumenttypdefinitionen zugrunde liegenden XML Schema Mit dieser Version hat sich die Spezifikation von Feldern, die auf den internen Feldern Identifier*, Subject* und Note basieren, geändert. Außerdem muss durch die Einführung eines neuen Schriftenreihen-Modells die Spezifikation für Felder, die auf der Collection Role Series basieren, verändert werden. Die Änderungen umfassen (jeweils bezogen auf die Elemente field): * enthält das Attribut name den Wert IdentifierOld, IdentifierSerial, IdentifierUuid, IdentifierDoi, IdentifierHandle, IdentifierOpus3 , IdentifierIsbn, IdentifierIssn, IdentifierUrn, IdentifierOpac, IdentifierUrl, IdentifierStdDoi, IdentifierCrisLink, IdentifierSplashUrl, IdentifierPubmed, oder IdentifierArxiv, so muss der Wert des Attributs datatype in Identifier geändert werden * enthält das Attribut name den Wert SubjectSwd oder SubjectUncontrolled, so muss der Wert des Attributs datatype in Subject geändert werden * enthält das Attribut name den Wert Note, so muss der Wert des Attributs datatype in Note geändert werden * enthält das Attribut name den Wert Series und hat das Attribut datatype den Wert Collection sowie das Attribut root den Wert series, so muss im Attrubut datatype der Wert Series eingetragen werden. Das Attribut root muss entfernt werden. Im Tarball findet sich unter install/update-documenttypes.php ein PHP-Skript, das die Umschreibung durchführt. Es erwartet als Eingabe die umzuschreibende Datei und optional die XML-Schemadefinition, gegen die das Resultat validiert werden soll. Wenn Sie die Instanz mit dem Update-Skript aktualisieren, müssen sie das Skript *nicht* manuell aufrufen (s.u.). In sämtlichen XML-Dokumenttypdefinitionen, die standardmäßig ausgeliefert werden, sind die Änderungen schon berücksichtigt. Sofern Sie beim Update die Änderungen übernehmen, sind keine weiteren Eingriffe erforderlich. Für benutzerdefinierte XML-Dokumenttypen führt das Update-Skript, sofern erforderlich, eine automatische Umschreibung durch. In diesem Fall wird eine Backup-Datei im Verzeichnis $BASEDIR/opus4/applications/config/doctypes angelegt, die z.B. für die Datei foo.xml mit foo.xml.update-backup. bezeichnet wird. Außerdem werden die benutzerdefinierten Dokumenttypdefinitionen gegen das XML-Schema (siehe nächster Punkt) validiert. Wird ein Schemaverstoß festgestellt, so wird der Dokumenttyp invalidiert, indem z.B. die Datei foo.xml in foo.xml.invalid. umbenannt wird. Alle Manipulationen werden im Logfile $BASEDIR/UPDATE-documenttypes.log protokolliert. h3. Änderung in der Verarbeitung der XML-basierten Dokumenttypdefinitionen Mit OPUS 4.2.0 werden die XML-basierten Dokumenttypdefinitionen (im Verzeichnis $BASEDIR/opus4/applications/config/doctypes) gegen das XML-Schema validiert, das im Verzeichnis $BASEDIR/opus4/library/Opus/Document/documenttype.xsd abgelegt ist. Wir empfehlen im Rahmen des Updates auf OPUS 4.2.0 sämtliche Dokumenttypdefinitionen auf Schema-Konformität zu testen, um so sicherzustellen, dass die Dokumenttypen weiterhin im Publikationsformular benutzt werden können. Einzelheiten dazu sind in Kapitel 8.4.6 der OPUS4-Dokumentation aufgeführt. Wenn Sie die Instanz über das Update-Skript aktualisieren, wird im Anschluss an die Aktualisierung der XML-Dokumenttypdefinitionen eine Validierung der unter $BASEDIR/opus4/applications/config/doctypes abgelegten XML-Dateien durchgeführt. Wird für eine Datei foo.xml ein Schemaverstoß festgestellt, so wird die Datei durch Umbenennung in foo.xml.invalid. invalidiert. Der Dokumenttyp kann dann nicht mehr im Publikationsformular ausgewählt werden. Die festgestellten Validierungsfehler werden in der Logdatei unter $BASEDIR/UPDATE-documenttypes.log protokolliert. Nach dem Beheben der Fehler können Sie den Dokumenttyp durch das Entfernen des Suffix .invalid. im Dateinamen wieder für die Auswahl im Publikations- formular freigeben. h3. Hinweis zu URNs von migrierten Dokumenten Wir haben einen Hinweis in die Dokumentation aufgenommen, die alle Instanzen betrifft, die bereits vor OPUS4 für die URN-Vergabe registriert waren. Bei der Migration müssen Sie in der config.ini den Präfix des NISS anpassen, um Kollisionen mit bereits vergebenen URNs zu vermeiden. Die Informationen finden Sie in Kapitel 7.6 "URN SETTINGS". Der entsprechende Schlüssel in der Config lautet "urn.nss". Hatten ihre URNs vor der Migration z.B. die Form "urn:nbn:de:kobv:123-opus-123x" für ein Dokument mit der ID 123, so genügt es den Schlüssel "urn.nss" auf den Wert "de:kobv:123-opus4" zu setzen. Die URN eines neuen Dokuments 123 lautet dann einfach "urn:nbn:de:kobv:123-opus4-123y" und kollidiert nicht mehr mit der ID 123 aus dem alten System. Weitere Details erhalten Sie in Kapitel 7.6 unserer Dokumentation, bei der DNB oder im Nestor-Handbuch: * http://nbn-resolving.de/urn/resolver.pl?urn=urn:nbn:de:0008-20100305176 h3. Neue Konfigurationsdatei für die Migration aus OPUS3 Mit OPUS 4.2.0 ändert sich die Konfiguration der Migration aus OPUS3. Für instanzspezifische Anpassungen steht im Verzeichnis $BASEDIR/opus4/applications/config/ das Template migration_config.ini.template zur Verfügung. Dieses muss vor Ablauf der Migration in migration_config.ini umbenannt werden. Kapitel 10.1 "Vorbereitung" beschreibt, welche Einstellungen manuell geändert werden können. Die alten Anpassungen aus $BASEDIR/opus4/applications/config/import.ini müssen vor der Migration nach migration_config.ini unter Berücksichtigung der neuen Konfigurationsschlüssel übetragen werden. h3. Validierung in Metadaten-Formularen (Administration) Es wurde angefangen die Validierung der Formulare umzusetzen. Es werden aber immer noch nicht sämtliche Fehleingaben abgefangen und es kann zu Exceptions kommen. In diesem Fall bitte den 'Back' Knopf im Browser verwenden und die Eingaben korrigieren. Es sollte bei einer Fehleingabe nicht zu korrumpierten Daten in der Datenbank kommen. h2. ======================== Release 4.1.4 2011-10-18 ======================== h3. Änderungen an Dateien im benutzerdefinierten Layout-Verzeichnis Wird ein Custom Layout verwendet, so müssen zwei Änderungen an CSS und JavaScript manuell nachgezogen werden, da das Update-Skript keine Veränderung an benutzerdefinierten Layouts vollzieht. Betroffen sind die Dateien * public/layouts/opus4/css/opus.css * public/layouts/opus4/js/searchutil.js Diese müssen in das eigene Layout durch Kopieren der Dateien übernommen werden. h3. Änderungen an Solr-Indexschema Wird der Solr-Server nicht im Rahmen des Updateskripts aktualisiert (weil er z.B. auf einem anderen Server betrieben wird), dann muss das Indexschema aktualisiert werden. Dazu muss die Datei * solrconfig/schema.xml in das Konfigurationsverzeichnis der Solr-Server kopiert werden und anschließend der Index neu erstellt werden mittels: cd $BASEDIR/opus4/scripts php SolrIndexBuilder.php h3. Umbenennung von benutzerspezifischen Enrichment-Feldern Mit OPUS 4.1.4 werden in der Standardauslieferung neue Enrichment-Felder eingeführt, die für die Migration von Dokumenten aus OPUS3 relevant sind: * ClassRvk * SourceTitle * SourceSwd * SourceSwb * ContributorsName * SubjectUncontrolledGerman * SubjectUncontrolledEnglish Damit im Rahmen eines OPUS4-Updates keine Konflikte mit identischen, vom Benutzer angelegten, Enrichment-Feldern auftreten, werden die benutzerdefinier- ten Enrichment-Felder vor dem Update auf OPUS 4.1.4 umbenannt in: * TempClassRvk * TempSourceTitle * TempSourceSwd * TempSourceSwb * TempContributorsName * TempSubjectUncontrolledGerman * TempSubjectUncontrolledEnglish Im Falle einer Umbenennung muss die Übersetzungsressource des alten Feldes angepasst werden. Zum Beispiel muss im Falle der Umbennung von SourceTitle in TempSourceTitle in der Datei $BASEDIR/opus4/modules/default/language_custom/custom.tmx folgende Änderung vollzogen werden: ersetze ... durch ...