Release-Buildnummern
IBSS API: 2.21.9662.19614
Plattform (Monza) EM-Dienst: 2.22.9652.25078
Plattform (Monza) Daten-API: 2.22.9567.18701
Plattform (Monza) Admin-API: 2.22.9648.22546
Was ist neu
Um neue Funktionen in Flex zu unterstützen
Status des Arbeitsortes
- Ein neuer Endpunkt zum Abrufen von Benutzereinstellungen für einen authentifizierten Benutzer: /v2/{nodeid}/UserPreferences
Parkplatzreservierungen
- Zur Unterstützung der neuen Funktion werden dem Endpunkt v2/{nodeid}/bookings nun zwei weitere Felder hinzugefügt:
- Parent_Booking_Id - Zeichenkette
- Parent_Booking_Relation_Type - Aufzählung
Teambuchungen
Die Möglichkeit, Teams zu erstellen und Buchungen für diese vorzunehmen, wurde der Plattform hinzugefügt. Zur Unterstützung dieser Funktion bieten wir nun Folgendes an:
- Neue TeamId- und TeamBookingId-Felder in den Endpunkten:
- POST v2/{nodeid}/bookingparties?bookingid={bookingid}
- POST v2/{nodeid}/bookingparties/import/{bookingid}
- Neue Endpunkte:
- GET v2/{nodeid}/bookings/team-bookings/{teambookingid}
- PATCH /v2/{nodeid}/spaces/{teambookingid}/team-checkin
- PATCH /v2/{nodeid}/spaces/{teambookingid}/team-checkout
- PATCH /v2/{nodeid}/bookings/team-bookings/{teambookingid}/cancel
- PATCH /v2/{nodeid}/bookings/team-bookings/{teambookingid}
Zur Unterstützung neuer Funktionen in OneLens
Besucher-Dashboard
Zur Unterstützung dieser Funktion wurden folgende Ergänzungen vorgenommen:
- V2/VisitSummaries/Daily/{start-date}/{end-date}
- V2/VisitSummaries/Weekly/{week-start-date}/{week-end-date}
- V2/VisitSummaries/Monthly/{month-start-date}/{month-end-date}
- Die Funktion zur Berechnung der durchschnittlichen Besuchsdauer in Minuten wurde für die wöchentlichen und monatlichen Zusammenfassungsdaten erweitert.
Neue Importfunktion
Benutzer mit der Berechtigung „Besucher erstellen“ können einzelne Besucher per Massenimport in IBSS importieren. Ein neuer API-Endpunkt wurde hinzugefügt, um dies zu unterstützen:
- /v2/{nodeid}/visits/import
Diverse Verbesserungen, um den Import von Cateringartikeln und Menüs zu ermöglichen. Zur Unterstützung dessen:
- Die neue Berechtigung API.CateringMenuItems.Import wurde zu den verfügbaren Rechten hinzugefügt.
- Der Webjob wurde erweitert, um den Import als Hintergrundaufgabe zu verarbeiten.
- Die Datei v2/{nodeid}/catering-menuitem/import wurde so geändert, dass sie die Importdatei verarbeiten kann.
Neue Exportfunktion
Nutzer können nun auswählen, welche Buchungsdaten in den Export einbezogen werden sollen. Dazu haben wir folgenden Endpunkt hinzugefügt:
- /v2/{nodeId}/bookings/download
Neue Catering-Berichte zum Download
Wir haben mehrere Standard-Cateringberichte zum Download erstellt. Diese werden von den folgenden neuen Endpunkten unterstützt:
- /v2/{nodeid}/catering-order/report/download
- /v2/{nodeid}/catering-menuitem/report/download
- /v2/{nodeid}/catering-order/report-supplier-cost/download
- /v2/{nodeid}/catering-order/{orderid}/report-catering-menuitem/download
- /v2/{nodeid}/costcodes/{costcode}/report-catering-orders/download
- /v2/{nodeid}/catering-order-policy/{cateringOrderPolicyId}/report-catering-menuitem/download
Zur Unterstützung neuer Funktionen im Admin-Portal
Gerätekonfiguration
Für die Bereitstellung Unity oder Inspire Anwendungen in einer Umgebung wurde eine neue Schnittstelle entwickelt, um Konfigurationsänderungen an diesen Anwendungen vorzunehmen. Hierfür stehen folgende Berechtigungen zur Verfügung:
- Neu: ADMINPORTAL.Manage.Devices
- Vorhanden: DATAMODEL.Devices.CRUD
Raumkonfiguration
Die Möglichkeit, die Raumkonfiguration etagenweise zu importieren und zu exportieren, wurde verbessert. Wir haben nun:
- Implementierung einer Hintergrundverarbeitung für Massenimporte in den Endpunkt v2/{NodeId}/spaceconfigurations/import
- Es wurde eine zusätzliche Validierung der Knoten-ID eingeführt.
- Das Feld Space_Light_Mode wurde hinzugefügt.
Gebäudeparameter
Die Möglichkeit, Konfigurationsparameter auf Gebäudeebene zu steuern, wurde hinzugefügt. Zur Unterstützung dieser Funktion wurden folgende Elemente hinzugefügt/aktualisiert:
- Berechtigungen
- Neue Berechtigung für die Seite: ADMINPORTAL.Manage.Parameters
- Vorhandene Berechtigungen: DATAMODEL.Parameters.CRUD
Aktualisierungen der Buchungsrichtlinien
- Kontrolle externer Teilnehmer. Sie können bestimmte Bereiche so einschränken, dass Nutzer dort keine externen Teilnehmer zu Buchungen hinzufügen können. Die App benachrichtigt den Nutzer nicht über die geänderten Buchungsbedingungen. Wir gehen davon aus, dass Bereiche mit Einschränkungen für externe Teilnehmer organisationsweit separat kommuniziert werden. Zur Unterstützung:
- Wir haben das neue Feld AllowExternalAttendees zu den folgenden Endpunkten hinzugefügt:
- POST /v2/{nodeid}/bookingpolicies
- PUT /v2/{nodeid}/bookingpolicies/{bookingpolicyid}
- Die Validierungsmethode ValidateAttendee der Buchungsparteien wurde erweitert, um zu prüfen, ob der Buchungsteilnehmer extern ist.
- Wir haben das neue Feld AllowExternalAttendees zu den folgenden Endpunkten hinzugefügt:
- Erweiterte Wiederholungsgrenze von 52 auf maximal 365 Ereignisse mit zusätzlichen Optionen:
- Der Parameter RecurrenceLimit dient dazu, sicherzustellen, dass keine Serie wiederkehrender Buchungen ein Kalenderjahr überschreitet.
- API.Bookings.IgnoreRecurrenceLimitsInPolicy-Berechtigung zum Überschreiben des durch eine Buchungsrichtlinie festgelegten Wiederholungslimits.
Was hat sich geändert?
Für alle Benutzer
- Die Sprachauswahl wurde allen Webanwendungen hinzugefügt.
- Wir haben die Unterstützung für passive Belegungssensordaten („Signs of Life“ – SoL) über einen neuen V2-Endpunkt /v2/{nodeid}/Spaces/update-space-occupancy hinzugefügt. Dadurch können Räume basierend auf der Sensoraktivität anstatt auf Buchungen als belegt markiert werden. Außerdem wurde der Gebäudeparameter SensorSignsOfLifeUpdates eingeführt, um die Nutzung der Sensordaten zu aktivieren.
- Wir haben die API-Unterstützung für die zukünftige Funktionalität hinzugefügt, bis zu 10 Bildanhänge zu einer erstellten Serviceanfrage hinzuzufügen. Diese Funktion wird in einer der nächsten Versionen von Flex und Roamer X verfügbar sein.
Für OneLens Nutzer
- Die Menge (Gesamtkapazität) wurde der monatlichen Übersicht der Raumauslastung auf der Seite „Buchungsanalysen“ hinzugefügt.
- Bei den Buchungsdatensätzen für Räume werden die Felder Space_Name und Space_Name_Label aus den Daten der angegebenen Raumdatensätze und nicht aus dem Buchungsdatensatz befüllt.
- Die Validierung für die im Update-Payload übergebene Ticket-Event-ID wurde hinzugefügt.
- Aktualisierte Validierungen der Endpunkte:
- POST/PUT/PATCH /v2/{nodeid}/catering-restriction/{cateringRestrictionId}:
- Die Knoten-ID kann nur vom Typ Gebäude sein.
- Der Abschnitt kann nur einen von zwei Zeichenkettenwerten annehmen: „Diät“ oder „Allergen“.
- Die Bild-URL ist eine gültige URL.
- POST/PUT/PATCH /v2/{nodeid}/catering-order-policy/{cateringOrderPolicyId}:
- Die Knoten-ID kann nur vom Typ Gebäude sein.
- Kitchen_OperatingHours_Start und Kitchen_OperatingHours_Stop müssen beide im Format HH:MM angegeben werden (z. B. 09:30).
- Kitchen_OperatingHours_Start darf nicht nach Kitchen_OperatingHours_Stop liegen.
- POST/PUT/PATCH /v2/{nodeid}/catering-restriction/{cateringRestrictionId}:
Für Administratoren
- Wir stellen unsere Produkte schrittweise auf ein neues Erscheinungsbild um und reorganisieren die Seitenstruktur, um eine verbesserte Benutzererfahrung und eine klarere Logik zu gewährleisten.
Als ersten Schritt haben wir einige Setup-Admin-Seiten auf einen neuen Speicherort umgeleitet. Betroffene Benutzer sehen den Weiterleitungslink auf diesen Seiten.
Für API-Nutzer
- Die PUT/PATCH-Funktionalität für Buchungen wurde aktualisiert, sodass beim Aktualisieren des Besucherausweises von 0 auf 1 ein Besuchsdatensatz erstellt und beim Aktualisieren des Besucherausweises von 1 auf 0 der Besuchsdatensatz storniert wird.
- Die Namensvorgabe für das Nodes-Objekt wurde entfernt. Bisher musste der Name für alle Objekte eindeutig sein; zukünftig sollte nur noch die Kombination aus Node_Id und Nodes-Name eindeutig sein.
- Bei der Standardbereitstellung werden nun automatisch Typen und Felder erstellt, um Fehler während der Bereitstellung zu reduzieren.
- Bei der Erstellung eines neuen Mandanten werden automatisch ein nativer Identitätsanbieter, ein nativer Administratorbenutzer und eine native Administratorrolle erstellt.
- Der Import von Informationen für eine Etage wurde mittels POST /v2/core/{tenancy}/nodes/{nodeid}/ import aktiviert.
- Verhindern, dass innerhalb desselben Mandanten doppelte Ontologienamen verwendet werden.
- Es wurde der PATCH-Endpunkt /v2/security/{tenancy}/users/{userid} hinzugefügt, um dem Benutzer die Möglichkeit zu geben, seinen bevorzugten Namen, seine Initialen oder eine Kombination aus beidem zu aktualisieren.
Was wurde behoben?
Gastronomie
- Wir haben das Feld „Gelöscht“ aus dem POST-Endpunkt /v2/{nodeid}/catering-templates entfernt. Dieses Feld ist nur in den PUT- und PATCH-Endpunkten enthalten.
- Exportanfragen für Catering-Lieferanten sind nun erfolgreich.
- Wir haben die folgenden Validierungen beim Erstellen und Aktualisieren von Catering-Bestellungen korrigiert:
- Menüpunkt-ID
- Kostenstellenzuordnung
- Gesamtwert Catering
- Catering-Servicezeit
- Reinigungszeit für Catering
- Die Validierung des ImageURI-Werts für POST/PUT/PATCH-Aufrufe von Catering-Menüs wurde korrigiert.
Buchungen
- Buchungen behalten nun nach dem Auschecken korrekt den Status „Abgeschlossen“ und wechseln danach nicht mehr zu „Nicht erschienen“.
- Das Hinzufügen von Teilnehmern zu einer Buchung wurde korrigiert. Zuvor musste für die Buchung ein Ereignis erstellt werden, um Teilnehmer aufnehmen zu können.
- Das Problem wurde behoben, bei dem beim Aktualisieren einer Buchung die zugehörigen Catering-Bestellungen wieder den Status „Genehmigung ausstehend“ erhielten. Catering-Bestellungen behalten nun ihren Status, wenn die Buchung aktualisiert wird.
- Beim Import von Teilnehmern wird das Feld Is_Remote = 1 bei der Kapazitätsprüfung nicht mehr berücksichtigt.
- Es wurde ein Fehler behoben, der die Aktualisierung des Buchungsraumdatensatzes beim Verschieben des Raumes innerhalb einer Etage behebt, wenn sich die Knoten-ID nicht ändert, die Raum-ID jedoch schon.
- Behoben: Aktualisierung des Buchungsinhabers, wenn ProcessBookingParties = false.
- Der Endpunkt PUT /v2/{nodeid}/bookings/{bookingid} wurde korrigiert, damit Benutzer Buchungsslots aktualisieren/zurücksetzen können.
- Einrichtungs-/Zurücksetzungsbuchungen werden wie vorgesehen automatisch zusammen mit der zugehörigen Hauptbuchung storniert.
- Der Benutzer kann nun eine Buchung eines verknüpften Raums abschließen, es wird kein Fehlercode 500 zurückgegeben und der Buchungsstatus ändert sich korrekt auf Abgeschlossen.
- Wir haben den Parameter SearchForDuplicatesIn in der Nutzlast von POST /v2/{nodeId}/bookings korrigiert, um ihn anhand der Regions-Node-ID zu validieren. Dadurch wird sichergestellt, dass Benutzer ohne die Berechtigung, unbegrenzt viele Räume desselben Typs zu buchen, korrekterweise nur einen Raum gleichzeitig in ihrer zugewiesenen Region buchen und nicht wie zuvor ein ganzes Gebäude.
- Wurde die Teilnehmerzahl bei einer Buchung mit automatisierter Cateringbestellung geändert, passte sich die Anzahl der Menüpunkte nicht entsprechend an. Wir haben dies für die Endpunkte /v2/{nodeid}/bookingparties/ behoben.
- Bei Buchungen von verknüpften Räumlichkeiten, in denen für eine der Räumlichkeiten eine automatische Cateringbestellung eingerichtet ist, werden diese Cateringbestellungen nun problemlos erstellt.
- Bei verknüpften Raumbuchungen funktionierte der automatische Check-in nicht für beide Räume. Jetzt werden die Statusinformationen beider Räume korrekt aktualisiert und die Buchungsdaten sind vorhanden.
- Das Genehmigen und Ablehnen von Buchungen über /v2/{nodeid}/bookings/{bookingid}/deny oder /v2/{nodeid}/bookings/{bookingid}/approve setzt die Felder „Buchungsbeginn“ und „Buchungsende“ nicht mehr auf null. Die Felder bleiben wie erwartet unverändert.
Ressourcen
- Der Status der Ressource wird wieder auf „verfügbar“ zurückgesetzt, nachdem sie aus der Buchung entfernt wurde, und sie kann erneut hinzugefügt werden.
- Ressourcen werden nach dem Hinzufügen zur Buchung nicht mehr dupliziert.
Weitere Korrekturen
- Die Berechnungen für Belegung, Auslastung und Spitzenbelegung wurden im folgenden Aufruf korrigiert: /v2/spaces-summary/daily/
- Der ConcurrencyStamp-Fehler wird im PUT-Aufruf auf der Seite „Admin Portal > Spaces“ behoben.
- Im Rahmen der laufenden Arbeiten haben wir die Fehlermeldungen an einigen Stellen aktualisiert, um aussagekräftigere Details hinzuzufügen. Beispielsweise liefert die API in den folgenden Szenarien eine aussagekräftigere Fehlermeldung:
- Wenn es während einer Aufgabenaktualisierung zu einem Konflikt kommt
- Wenn ein Benutzer versucht, sich mit der falschen PIN im Bereich einzuchecken
- Beim Importieren von Veranstaltungsteilnehmern über /v2/nodeid/ticketedevents/participants/import wurde früher ein 500 Internal Server Error zurückgegeben. Dieses Problem ist nun behoben.
- Die Dateien /v2/{nodeid}/visits/import und /v2/{nodeid}/visits wurden korrigiert, sodass der Besuchsdatensatz nun die Visit_Host_Email in Kleinbuchstaben enthält. Zuvor wurden Großbuchstaben gespeichert.
- Wir haben das Feld Space_Clean_Status zur SpacesConfiguration-Entität hinzugefügt, damit die Werte beim Import akzeptiert werden.
Bekannte Probleme
Gastronomie
- Wird eine Buchung auf eine andere Etage und in einen anderen Bereich verschoben, in dem die automatische Cateringbestellung eingerichtet ist, kann die automatische Cateringbestellung nicht erstellt werden. In diesem Fall müssen Cateringbestellungen manuell erstellt werden.
- /v2/{nodeid}/catering-menu/{cateringMenuId} ermöglicht die Rückgabe eines Menüs mit einer anderen gültigen Knoten-ID als derjenigen, die mit dem Catering-Menü verknüpft ist.
Besucher
- Die VisitorTypeId wird für den Buchungsdatensatz und den Besuchsdatensatz nicht korrekt aktualisiert, wenn Buchungsteilnehmer hinzugefügt oder entfernt werden.
- Das Erstellen eines Besuchs über /v2/{nodeid}/visits birgt folgende Probleme (Hinweis: Diese Probleme treten nur bei direkter Verwendung der API auf; die Benutzeroberfläche behebt diese Probleme):
- Wenn die Space-ID angegeben wird, wird der Space-Name nicht automatisch ausgefüllt. Der Space-Name bleibt leer.
- Der Benutzer kann einen Besuchsdatensatz auch ohne Angabe einer E-Mail-Adresse/eines Namens des Gastgebers erstellen.
- Die Felder Visitor_Dietary_Pref und Visit_Save_Info werden nicht validiert oder im Besuchsdatensatz gespeichert.
- Beim Import der Besucherdatei werden keine Besuchsdatensätze mit ausgefüllter Space_Id, Besuchertyp und PACS-ID erstellt.
Weitere Korrekturen
- /v2/configuration/{nodeid}/spaces/{spaceId} erlaubt die Rückgabe von Spaces mit der falschen Knoten-ID.
- /v2/{nodeid}/tag2eventtype - Das Angeben eines OrderBy-Feldes führt nicht zur Sortierung der Antwort.
- /v1/Devices/{deviceId} aktualisiert die MAC-Adresse des Geräts nicht, wenn sie leer ist.
- /v2/{nodeid}/shortcuts ermöglicht das Erstellen einer Verknüpfung mit einem Startdatum nach dem Enddatum.
- /v2/{nodeid}/bookings/{bookingid} aktualisiert die Details des Gastgebers/Inhabers nicht, wenn der Buchungsinhaber aktualisiert wird.
- In den folgenden Szenarien wird ein Erfolgscode anstelle eines Fehlers zurückgegeben:
- Beim Erstellen einer Buchungsgruppe mit fehlenden Feldern in /v2/{nodeid}/bookingparties wird der Code 200 anstelle des Codes 422 zurückgegeben.
- POST /v2/Users/check-pin - Nullwert oder leere Zeichenkette für PIN oder ungültiger numerischer Wert für UserName geben nicht 422 zurück.
- Die Ausführung von PUT /v1/NotificationHubRegister/{id} und DELETE /v1/NotificationHubRegister/{id} mit der ungültigen ID liefert nicht wie erwartet den Fehler 404. Die Antwort ist entweder leer oder gibt den Code 200 mit der Begründung „Ungültige Anfrage“ zurück.
- GET /v2/{nodeId}/visits-summary/daily/{startDate}/{endDate} - Enddatum vor dem Startdatum gibt Code 200 anstelle von Code 422 zurück.
- POST /v2/{nodeid}/catering-order gibt 201 statt 422 Missing Status Code zurück, wenn Booking_Id nicht existiert.
- POST /v2/{nodeid}/bookingparties - Der Benutzer kann Pass, IsRemote, IsParticipant_On_WaitingList, IsExternal all = 1 für eine Party vom Typ 3 setzen, obwohl eigentlich ein 422-Fehler zurückgegeben werden sollte.
- Es besteht noch Verbesserungsbedarf bei der Standardisierung von Fehlermeldungen über mehrere Endpunkte hinweg, um HTTP-Statuscodes zu korrigieren.