[Kobv-opus-tester] Testmigration auf OPUS 4.2.0 (ein Problem beim Editieren der Abstracts im Admin-Bereich)

Heidi Traeger htr at uni-weimar.de
Mon Feb 6 12:04:38 MET 2012


Liebe Liste, liebes Entwickler-Team,

ich habe in Weimar auch auf 4.2.0 aktualisiert und hatte den gleichen 
Fehler. Ich habe vorerst in der Datei die gesamte Abfrage  if 
($editMode) ... auskommentiert.

Ausserdem wurden die Titel in den Schriftenreihen nur im Admin-Bereich 
angezeigt. Auch die Sortierung funktioniert nur mit Manipulation. Wenn 
ich im Admin-Bereich eine Sortierziffer eingebe und abspeichere 
erscheint wieder der vorherige Wert.
Ich habe mit phpMyAdm die Sortierung geändert und dann bei jedem 
einzelnen Schriftenreihen-Titel im Admin-Bereich den Abschnitt 
Schriftenreihe bearbeitet (ohne etwas zu tun) und abgespeichert. Das 
hatte den Effekt, dass diese Titel dann auch im Frontdoor in den 
Schriftenreihen sichtbar waren.
Auch die Sortierziffer der Schriftenreihe änderte sich dabei immer mal 
und ich musste sie neu setzten. Hier klappt das Speichern.
Die Verlinkung der Schriftenreihen gefällt uns aber so gut, dass die 
Arbeit es Wert war.

Und noch eine gute Nachricht, auch in Weimar funktioniert das 
Umschreiben der alten OPUS3-URLs; ich musste in unserer Installation den 
Slash vor  Volltexte (^volltexte..) weglassen.

Beste Grüße
Heidi Traeger

Am 06.02.2012 10:19, schrieb Sven Heitmann [UB]:
> Liebes OPUS4-Entwickler Team,
>
> wir haben unsere Testumgebung erfolgreich von OPUS 4.1.3 auf OPUS 4.2.0
> aktualisiert und über die neue Version ziemlich 'amused' ... denn viele
> der uns bisher bekannten Probleme haben sind damit gelöst. :-)
>
> Nur zwei Probleme sind uns bisher aufgefallen:
>
> (1)
> Verwendet man im "Admin"-Bereich in der Verwaltung eines Dokumentes bei
> "Abstract(s)" die Funktion "Neu hinzufügen" und versucht das neue
> Abstract dann zu speichern, erscheint eine Fehlermeldung (im
> Testing-Modus). Die gleiche Fehlermeldung erscheint beim Verwenden der
> Funktion "Bearbeiten" zum Editieren der Abstracts.
>
> Hier die Fehlermeldung:
> "Fatal error: Call to a member function setAttrib() on a non-object in
> /srv/www/opus420/opus4/modules/admin/controllers/DocumentController.php
> on line 612 Call Stack: 0.0002 655880 1. {main}()
> /srv/www/opus420/opus4/public/index.php:0 0.1168 13697080 2.
> Zend_Application->run() /srv/www/opus420/opus4/public/index.php:74
> 0.1168 13697080 3. Zend_Application_Bootstrap_Bootstrap->run()
> /srv/www/opus420/libs/ZendFramework-1.10.6-minimal/library/Zend/Application.php:366
> 0.1169 13697184 4. Zend_Controller_Front->dispatch()
> /srv/www/opus420/libs/ZendFramework-1.10.6-minimal/library/Zend/Application/Bootstrap/Bootstrap.php:97
> 0.1414 15065456 5. Zend_Controller_Dispatcher_Standard->dispatch()
> /srv/www/opus420/libs/ZendFramework-1.10.6-minimal/library/Zend/Controller/Front.php:954
> 0.1504 16512120 6. Zend_Controller_Action->dispatch()
> /srv/www/opus420/libs/ZendFramework-1.10.6-minimal/library/Zend/Controller/Dispatcher/Standard.php:295
> 0.1507 16520120 7. Admin_DocumentController->editAction()
> /srv/www/opus420/libs/ZendFramework-1.10.6-minimal/library/Zend/Controller/Action.php:513
> 0.1948 19540352 8. Admin_DocumentController->__getEditForm()
> /srv/www/opus420/opus4/modules/admin/controllers/DocumentController.php:110
> 0.2051 21015384 9. Admin_DocumentController->__getFormForField()
> /srv/www/opus420/opus4/modules/admin/controllers/DocumentController.php:545
> "
> /srv/www/opus420/opus4/modules/admin/controllers/DocumentController.php"
>
> Durch leichte Anpassungen an der Datei
> "./opus420/opus4/modules/admin/controllers/DocumentController.php"
> konnte ein Kollege die Fehlermeldung abstellen:
> " [...]
>       private function __getFormForField($field, $doc, $editMode = false) {
>           $subform = null;
>           switch ($field->getName()) {
>               case 'Licence':
>                   $subform = new Admin_Form_Model(
>                           'Opus_Document', array('Licence'));
>                   break;
>               case 'Series':
>                   $subform = new Admin_Form_SeriesEntry($doc);
>                   break;
>               default:
>                   $subform = new Admin_Form_Model($field);
>                   // TODO hack for OPUSVIER-1544 to make SortOrder mandatory
>                   if ($editMode) {
>                       if (strpos($field->getName(), 'Person') === 0) {
>                           $subform->getElement('SortOrder')
>                                   ->setRequired(true);
>                       }
>                       else if (strpos($field->getName(), 'Title') === 0
> &&  $field->getName() !== 'Title') {
> // UB
>                           if ($subform->getElement('Type')) {
> // /UB
>
> $subform->getElement('Type')->setAttrib('disabled', 'disabled');
> // UB
>                           }
> // /UB
>                       }
>                   }
>                   break;
>           }
>           return $subform;
>       }
> [...]"
>
> Ob unser Lösungsversuch allerdings alltagstauglich ist? Da sind wir uns
> leider nicht sicher ...
>
> (2)
> Wir haben versucht bezüglich DINI-Zertifikat eine Sammlung "open_access"
> anzulegen und diese als OAI-Set auszugeben. Leider ohne Erfolg. Das ein-
> bzw. ausblenden im Browsing und Frontdoor funktioniert einwandfrei.
> Die Einstellung "Sammlung als OAI-Set ausgeben" scheint ignoriert zu werden.
>
>
> Viele Grüße aus Kaiserslautern
> Sven Heitmann
>

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : htr.vcf
Dateityp    : text/x-vcard
Dateigröße  : 325 bytes
Beschreibung: nicht verfügbar
URL         : http://listserv.zib.de/pipermail/kobv-opus-tester/attachments/20120206/7ca79385/htr.vcf