[Fenster schließen]    [Hilfe-Übersicht]

• Die vorliegende Version 2.01 der Publikationsdatenbank ist die erste, die offiziell außerhalb der TU Wien im Produktionsbetrieb zum Einsatz kommt: Die Publikationsdatenbank läuft nun auch im Intranet der Austrian Research Centers (ARC). Bemerkenswert ist, dass ihre Vorgänger-Version (V. 2.00c) trotz einer radikal unterschiedlichen Software-Umgebung in der ARC-Implementierung (anderes Linux-Betriebssystem, andere Versionen von PHP und MySQL) innerhalb weniger Stunden voll funktionsfähig war, was die Stabilität der Publikationsdatenbank unterstreicht. (Die vereinzelten Modifikationen, die für eine volle Funktionsfähigkeit der Publikationsdatenbank am ARC-Server erforderlich waren und in V. 2.01 enthalten sind, wären früher oder später, spätestens bei der nächsten Neuinstallation des Publikationsdatenbanks-Servers, auch an der TU Wien notwendig geworden.) Der Grund für die offensichtlich hervorragende Portabilität der Publikationsdatenbank-Software liegt in ihrem sorgfältig überlegten Konzept und den aufwändigen und rigorosen Tests, denen der Autor die Publikationsdatenbank routinemäßig unterwirft. Dies wird auch durch den Umstand illustriert, dass sich die Publikationsdatenbank - im Gegensatz zu SAP - auf Anhieb als voll kompatibel mit Internet Explorer 7 erwiesen hat. (Versuchsweise läuft die Publikationsdatenbank übrigens auch seit Monaten auf mehreren Windows-basierten Rechnern des Autors, wo gegenüber der Linux-Version ebenfalls nur die Standard-Konfigurationsdateien - einige wenige von weit über 300 PHP-Programmdateien - geändert werden mussten.)
• Version 2.01 wurde auch erfolgreich mit Internet Explorer 7 getestet und für diesen Browser approbiert; es konnten keine Inkompatibilitäten im Vergleich zu den übrigen getesteten Browsern festgestellt werden.
• Auf allen öffentlich zugänglichen Seiten der Publikationsdatenbank sowie im Administrationsprogramm (mit Ausnahme der nur für Administratoren zugänglichen Seiten) können jetzt "kleine" Formularelemente (Checkboxes, Radio Buttons) auch durch Klicken auf den zugehörigen Text betätigt werden; es ist daher nicht mehr ein genaues "Zielen" mit dem Mauscursor erforderlich. Ein "flächendeckender" Einsatz dieses Features im Administrationsprogramms ist derzeit noch unterblieben, weil seine Implementierung insbesondere deshalb relativ aufwändig ist, weil einzelne Browser (konkret unter den getesteten Opera 7.23) beim Klicken auf die Formularelement-Beschriftung nicht den mit dem Formularelement assoziierten JavaScript-Event Handler ausführen und dadurch - in einigen Fällen fatale - Fehlfunktionen auftreten könnten, soferne nicht aufwändige Workarounds vorgesehen werden. Grundsätzlich funktioniert dieses Feature, wo implementiert, korrekt mit (in alphabetischer Reihenfolge) Firefox (alle Versionen), Internet Explorer (ab Version 5.5), Mozilla (alle Versionen), Netscape (ab Version 6) und Opera (ab Version 7).
• In neueren Versionen des Datenbank-Backends (MySQL) wird unter bestimmten Voraussetzungen eine neue Implementierung einer Funktion zum verschlüsselten Abspeichern von Passworten verwendet, die mit der bisher verwendeten Funktion nicht kompatibel ist. Dies könnte dazu führen, dass - etwa nach einer Neu-Installation des Datenbank-Servers - alle Benutzer-Passworte ungültig würden und ein Login damit unmöglich wäre. Bevor dieses Problem akut wird, wurde ein neuer, (hoffentlich nachhaltigerer) Verschlüsselungs-Algorithmus für die Benutzer-Passworte implementiert, der zudem (was immer es Wert sein mag) den Vorteil hat, sicherer zu sein (160 statt 64 Bit Verschlüsselungstiefe). Völlig transparent für die Benutzerinnen und Benutzer wird ein mit dem alten Algorithmus abgespeichertes Passwort beim ersten erfolgreichen Login nach der Implementierung dieser Programm-Version durch ein mit dem neuen Algorithmus generiertes ersetzt; es ist dazu also keine wie immer geartete zusätzliche User-Interaktion erforderlich. (Der Autor hofft, damit etwas unabhängiger von der in der jüngeren Vergangenheit bei MySQL geübten Praxis geworden zu sein, bestimmte Funktionalitäten überfallsartig von einer Version auf die nächste durch inkompatible andere zu ersetzen.)
• Die Auswahllisten für Organisationseinheiten - Institute bzw. Gruppen - wurden bisher nach den Kurzbezeichnungen der Organisationseinheiten sortiert. Für Implementierungen, wo eine derartige Sortierung nicht sinnvoll oder erwünscht ist, wurde als primäres Sortier-Kriterium ein Reihenfolge-Parameter eingeführt, der je nach Implementierung ausgeblendet ist oder editiert werden kann. In Implementierungen, die dieses Feature nicht benötigen, haben alle Organisationseinheiten den gleichen Reihenfolge-Parameterwert (nämlich "0"); dort werden daher wie bisher die Listen nach den Kurzbezeichnungen der Organisationseinheiten sortiert.
• In allen Auswahllisten für Institute im Administrationsprogramm werden "ausgeblendete" Institute nur mehr dann angezeigt, wenn ihnen noch Personen (und damit potenziell andere Informationen wie Publikationen oder Projekte) zugeordnet sind. Die in der Folge von Umstrukturierungen übrig gebliebenen "toten" Institute verschwinden daher auch im Administrationsprogramm aus den Auswahllisten. (In der öffentlich zugänglichen Seite "Suche in der Publikationsdatenbank der Fakultät" und ähnlichen Seiten wurden sie schon bisher ausgeblendet.) Einträge nicht ausgeblendeter Institute werden aber in jedem Fall angezeigt, gleichgültig, ob ihnen Personeneinträge zugeordnet sind oder nicht.
• Eine weitere, durch Änderungen in MySQL bedingte "Zeitbombe" konnte entschärft werden: Die in den ursprünglichen Versionen der Publikationsdatenbank verwendeten MySQL-Versionen (3.22 und 3.23) unterstützten keine Datums-Angaben, bei denen Monat und/oder Tag auf "00" gesetzt waren (z.B. "2002-00-00"); solche Datumswerte wurden auf "0000-00-00" gesetzt. Da zu diesem Zeitpunkt alle Monatszahlen zwischen 1 und 12 und Tage zwischen 1 und 31 von MySQL als gültig akzeptiert wurden, wurde zur Kennzeichnung von Zeitangaben (z.B. Datum einer Veranstaltung), bei denen Tag und/oder Monat nicht mehr eruierbar waren, der 31. Februar als "Platzhalter" herangezogen. MySQL-Version 4 unterstützt weiterhin dieses Format, lässt aber auch den Wert "00" für Monat und Tag zu. Bei der Migration der Publikationsdatenbank von MySQL 3 auf MySQL 4 war also kein Handlungsbedarf gegeben. MySQL 5 prüft hingegen Datumsangaben rigoros auf Gültigkeit, wobei auch Schaltjahre berücksichtigt werden. Alle ungültigen Datumsangaben, also z.B. "2006-02-29" werden kommentarlos auf "0000-00-00" gesetzt; bei einer Umstellung der TU-Publikationsdatenbank auf MySQL 5 wären damit schlagartig mehrere hundert Datensätze, die das "Platzhalter"-Datum "JJJJ-02-31" enthalten, fehlerhaft geworden (und die Datums-Information wäre unwiederbringlich verloren gewesen). Da MySQL 5 jedoch ebenso wie MySQL 4 Datumsangaben in der Form "JJJJ-MM-00" oder "JJJJ-00-00" unterstützt, wird nun dieses (an sich ohnedies logischere) Format als "Platzhalter" bei unbekanntem Tag oder Monat und Tag verwendet, wobei jetzt beide genannten Varianten eingesetzt werden können. Damit kann als Zeitpunkt einer Veranstaltung beispielsweise "2006-12-11", "2006-12-00" (für "12/2006") oder "2006-00-00" (für "2006") angegeben werden. Die Eingabefelder für Datumswerte (auch für die Auswahloptionen z.B. im Hauptmenü) wurden entsprechend angepasst und erlauben jetzt auch die Eingabe von "00" für Monat und/oder Tag, wobei allerdings das Tages-Feld dann auf "00" gesetzt sein muss, wenn für den Monat "00" angegeben wird. Bestehende alte "Platzhalter"-Daten werden umgesetzt.
• Für jeden Publikationseintrag kann jetzt auch eine "zusätzliche" Datei auf den Datenbank-Server hochgeladen werden, die analog zu der für die Validierung verwendeten behandelt wird und diese ergänzt: Bei elektronischen Versionen von Publikationen, bei denen nicht - beispielsweise aus einer Fußzeile - die Zeitschrift oder der Tagungsband erkennbar ist, in der oder dem die Publikation erschienen ist, musste bisher die Titelseite und/oder das Inhaltsverzeichnis der Zeitschrift oder des Tagungsbandes mit einem PDF-Editor der eigentlichen Publikation vorangestellt werden, was relativ aufwändig war und entsprechende Software-Ressourcen erforderte. Diese Zusatz-Informationen können nun separat auf den Publikationsdatenbank-Server hochgeladen werden; man kann also die meist ohnehin vorhandene Publikations-Datei unverändert verwenden und braucht nur mehr eine PDF-Version der Titelseiten zu generieren, was inzwischen sogar mit modernen Kopierern sehr problemlos möglich ist. Ebenso wie die für die Validierung verwendete "verborgene" Datei ist auch die Datei mit den Zusatz-Informationen nur innerhalb des Administrationsprogramms zugänglich und sichtbar.
• Der Algorithmus für die Erstellung von Default-Passwörtern auf der Seite "Benutzerrechte bearbeiten" wurde überarbeitet: Der alte Algorithmus generierte Passwörter, die Interpunktions- und Sonderzeichen enthalten konnten, und die dementsprechend schwer les- und kommunizierbar waren. Der neue Algorithmus erzeugt Default-Passwörter, die nur mehr aus Ziffern und/oder Kleinbuchstaben bestehen. Die Länge der Default-Passwörter ist mit 8 Zeichen gleich geblieben. Da die User ja die Möglichkeit haben, sich bei ihrem ersten Login ein ihnen angenehmeres Passwort einzurichten (und das auch tun sollten), wurde kein weiterer Aufwand getrieben, um leichter merkbare Default-Passwörter zu generieren. Mit dem alten Algorithmus erstellte Default-Passwörter bleiben selbstverständlich gültig!
• Für Benutzerinnen und Benutzer mit dem Recht zum Editieren von Bewertungen wurde die Möglichkeit zum Export und Import von Evaluierungsabfragen neu geschaffen. Damit ist es möglich, die mit teilweise sehr großem Aufwand erstellten (und wegen ihrer potenziellen Bedeutung für die Allokation von Ressourcen auch sehr kritischen) Abfragen einerseits zu archivieren und andererseits zwischen verschiedenen Publikationsdatenbanken auszutauschen. Die Exportdateien für Evaluierungsabfragen werden in einem ASCII-Format erstellt, sind also mit jedem Texteditor (zur Kontrolle) lesbar. Sie enthalten jedoch Prüf-Informationen, die jede unbeabsichtigte oder beabsichtigte Änderung des Inhalts der Datei zu erkennen erlauben und einen Import manipulierter Evaluierungsabfragen-Dateien unterbinden. Der Export von Evaluierungsabfragen ist jeder Benutzerin und jedem Benutzer mit dem Recht zum Editieren von Bewertungen sowohl aus den lokalen als auch aus den globalen Tabellen möglich; ein Import setzt jedoch Editierrechte in den gewählten Ziel-Tabellen voraus, ist also für die globalen Tabellen nur für einen Master-Administrator (Loginname "$Adminx") zulässig. Der Export und Import erfolgt immer für eine gesamte Abfragen-Version. Bestehende gleichnamige Abfrage-Versionen (mit gleichem Gültigkeits-Zeitraum) werden beim Import nur dann überschrieben, wenn die Benutzerin / der Benutzer auf der Import-Seite eine Checkbox "Eine allenfalls bestehende gleichnamige Abfragen-Version überschreiben" gesetzt hat.
• In der nur für speziell berechtigte User zugänglichen Seite "Evaluierungsdaten ermitteln" wurden die folgenden Änderungen vorgenommen, die insbesondere bei der Durchführung einer Reihe von Abfragen über unterschiedliche Evaluierungszeiträume eine wesentliche Erleichterung der Bedienung mit sich bringen und dazu beitragen, dass Fehlerquellen vermieden werden:
  • Beim Aufruf der Seite "Evaluierungsdaten ermitteln" sind die Felder "Zeitraum von" und "Zeitraum bis einschließlich" jetzt auf das Jahr nach der letzten abgeschlossenen Evaluierung gesetzt. Wenn also 2005 das letzte Jahr mit einer abgeschlossenen Evaluierung war, sind die beiden genannten Felder auf "2006" voreingestellt.
  • Die Auswahl der (voraussichtlich) passenden Evaluierungsabfragen-Version erfolgt automatisch nur mehr beim Aufruf der Seite "Evaluierungsdaten ermitteln" bzw. beim Wechsel zwischen den globalen und lokalen Tabellen. (Diese Auswahlfunktion kann erneut durch Klicken auf den (bereits gesetzten) Radio Button "Abfrage aus lokalen Tabellen" bzw. "Abfrage aus globalen Tabellen" oder den zugehörigen Text aktiviert werden.)
  • Bei einer Änderung des Evaluierungszeitraums bleibt jetzt aber die einmal gewählte Abfragen-Version erhalten (wenn sie nicht explizit oder wie im vorigen Punkt beschrieben geändert wurde). Es kann also nicht mehr passieren, dass beim Wechsel des Evaluierungsjahres unbemerkt eine gar nicht erwünschte Abfragen-Version selektiert wird.
• Sehr vereinzelte (nicht zuletzt in der ARC-Implementierung manifest gewordene) Bugs und Unsauberkeiten wurden behoben.