openlibraryenvironment/gokb

Improve provider office for technical support

Closed this issue · 1 comments

Es gibt eine starke Anforderung, den technischen Support in Form einer Mailadresse für Anbieter aufzunehmen.

Zwei bisher diskutierte Lösungen sind:

  1. Nutzung von "Additional Properties" in der Organisations-Sicht, siehe #280
  2. Nutzung der bisher ungenutzten "Office"-Klasse für Organsiationen.

Anforderung

Die Anforderungen sind (Überarbeitet 2020 November)

  • Aufnahme einer "Technischer Support"-Mailadresse für den Anbieter
  • Aufnahme einer präferierten Sprache (neu!)
  • Darstellung und Bearbeitung in der neuen GUI in der Providersicht

Umsetzung

Die "alte" Umsetzung über "Additional Properties" wird verkompliziert, wenn verschiedene Sprachen berücksichtigt werden soll. Zukunftssicherer, auch für mögliche weitere Attribute des Supports, ist tatsächlich die "Office"-Variante. Das bedeutet

  • Einführung neuer Felder in der Domänenklasse Office
    • Officetyp als Referenz auf RefdataValues mit neuer RefdataCategory. Da zurzeit nur ein "technical support" unterstützt werden soll, reicht hier dieser Wert aus.
    • Sprache: Hier kann ggf. die RefdataCategory KBComponentVariantName.Locale nachgenutzt werden.
  • Implementierung in alte GUI
  • Rest-API für Office erstellen
  • Ausgabe per OAI-PMH als Objekt im Endpunkt /oai/orgs (Right now, there is a seperate office endpoint, but offices are not included in the org endpoint. The org endpoint should be extended to export the offices too. The undocumented office endpoint should be ignored by now. )
  • Reduzierte Einbettung in neue GUI, siehe Ticket openlibraryenvironment/gokb-ui#38. Reduziert meint, dass anhand der Anforderungen eine nutzerfreundliche Bearbeitung von Mailadresse und Sprache reichen.

Additional question: Right now an office has its own curatory group. Is this correct so?