Improve provider office for technical support
Closed this issue · 1 comments
darupp commented
Es gibt eine starke Anforderung, den technischen Support in Form einer Mailadresse für Anbieter aufzunehmen.
Zwei bisher diskutierte Lösungen sind:
- Nutzung von "Additional Properties" in der Organisations-Sicht, siehe #280
- 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.
darupp commented
Additional question: Right now an office has its own curatory group. Is this correct so?