Phönix

In den Stammdaten einer Lehrkraft gibt es in der Detailansicht künftig zusätzlich ein Feld „Nachgestellter Titel“. Dort können nach dem Namen geführte Titel wie z. B. „MSc“ oder „MBA“ als Freitext eingetragen werden. Das Feld ist optional und kann auch leer bleiben, ohne dass beim Speichern ein Fehler entsteht. Eingaben werden gespeichert und beim erneuten Öffnen der Lehrkraft-Detailansicht wieder korrekt angezeigt. Das neue Feld befindet sich im gleichen Bereich wie der bereits vorhandene vorgestellte Titel (z. B. „Dr.“), sodass beide Angaben zusammen gepflegt werden können. Dadurch lassen sich Dozententitel vollständiger und strukturierter erfassen. Das unterstützt insbesondere Auswertungen und Berichte, z. B. für Jahresberichte nach Titeln oder Abschlüssen.

In der Verwaltung der Ausschlusszeiten können Sie künftig neben globalen und dozentenspezifischen Zeiten auch raumspezifische Ausschlusszeiten erfassen und pflegen. Beim Anlegen oder Bearbeiten wählen Sie dafür den Typ „raumspezifisch“ und müssen anschließend verbindlich einen Raum auswählen; bei allen anderen Typen wird kein Raum hinterlegt. In der Listen- und Detailansicht wird der zugehörige Raum angezeigt, und der Typ „raumspezifisch“ steht auch im Filter zur Verfügung.

Bei der Terminplanung werden diese raumspezifischen Ausschlusszeiten automatisch berücksichtigt, sobald einem Termin ein Raum zugewiesen ist. Überschneidungen führen dabei – wie bei bestehenden Konfliktprüfungen – zu einer Warnung, der Termin wird also nicht blockiert. Termine ohne Raumzuweisung werden von raumspezifischen Ausschlusszeiten nicht beeinflusst. Dadurch können Nicht-Verfügbarkeiten einzelner Räume (z. B. Sperrzeiten) gezielter gepflegt werden, ohne andere Räume oder Termine unnötig zu betreffen.

Verbesserung beim Anlegen von Tenant-Dozenten (TenantTeacher)

Beim Erstellen eines TenantTeachers unter /tenantteachers/create/ muss künftig kein globaler Dozent (Teacher) mehr vorher existieren.

Was ändert sich?

• Automatische Anlage des globalen Dozenten:
  Wenn beim Speichern noch kein passender globaler Teacher vorhanden ist, wird dieser im Hintergrund automatisch erstellt und direkt mit dem neuen TenantTeacher verknüpft.
• Dubletten-Warnung statt Abbruch:
  Bevor final gespeichert wird, prüft das System, ob es möglicherweise bereits einen passenden Dozenten gibt (Abgleich über Vorname + Nachname, optional zusätzlich Geburtsdatum, falls angegeben).
• Bei möglichen Treffern erscheint eine Warnung mit Anzeige der gefundenen Kandidaten.
• Du kannst dann entscheiden: „Trotzdem anlegen“ und fortfahren.
• Ohne diese Bestätigung wird noch nicht gespeichert (du bleibst im Formular und siehst die Warnung).

Wichtig: E-Mail-Adressen bleiben getrennt

• Die globale Teacher-E-Mail (meist private Adresse) und die mandantenspezifische TenantTeacher-E-Mail (z.B. dienstliche Adresse je Mandant) werden nicht vermischt und nicht gegenseitig überschrieben.

Nutzen für dich

• Du kannst Dozenten schneller und ohne Vorarbeit anlegen, auch wenn sie global noch nicht erfasst sind.
• Gleichzeitig hilft dir die Warnung vor möglichen Dubletten, versehentliche doppelte Datensätze zu vermeiden – ohne dich im Prozess zu blockieren.

Erweiterte Auswahl „Abschlussart“ im Dozentenprofil

In der Dozentenmaske (TenantTeacher-Profil) wird die Auswahl „Abschlussart“ erweitert und präzisiert. Statt der bisherigen Option „Diplom“ können künftig „Diplom Uni“ und „Diplom FH“ getrennt ausgewählt werden. Zusätzlich kommt die Option „kein Abschluss“ hinzu, z. B. für Gastdozenten.

Neue Auswahlmöglichkeiten (exakt): - Promotion
- Master
- Diplom Uni
- Diplom FH
- Bachelor
- kein Abschluss

Was passiert mit bestehenden Daten?

Bisher gespeicherte Dozenten mit Abschlussart „Diplom“ bleiben nach dem Update gültig:
Sie werden automatisch auf „Diplom Uni“ umgestellt, damit es keine Fehler beim Anzeigen oder Speichern gibt.

Nutzen / Mehrwert für Anwender

• Genauere Erfassung von Abschlüssen durch die Unterscheidung zwischen Uni- und FH-Diplom.
• Bessere Abbildung von Gastdozenten, da „kein Abschluss“ explizit auswählbar ist.
• Stabiler Übergang ohne Nacharbeit, weil vorhandene „Diplom“-Einträge automatisch korrekt übernommen werden.

Hinweis zur Master-Berechtigung

Die Prüfung, ob ein Dozent Master unterrichten darf, kann die neuen Abschlussarten nun technisch unterscheiden und behandelt „kein Abschluss“ als nicht ausreichend für Master-Unterricht. Weitere Regeln bleiben wie bisher im System definiert.

Mit diesem Issue wird im System eine zentrale Druck-/PDF-Grundlage geschaffen: Ein einheitliches Printing-Framework im Core, das HTML-Vorlagen zuverlässig als PDF erzeugen kann.

Was ändert sich für Anwender?

• Das System bekommt die technische Basis, um Dokumente künftig im gleichen Stil als PDF auszugeben – unabhängig davon, aus welchem Modul sie kommen.
• PDFs können dabei von Anfang an typische Druckanforderungen abdecken:
• Fußzeile auf jeder Seite (z. B. für Standardinformationen)
• abweichendes Layout für die erste Seite (z. B. andere Abstände/Platz für Briefkopf)
• Seitenzahlen („Seite X von Y“)
• Die Ausgabe ist so ausgelegt, dass Logos, Schriften und Styles sauber eingebunden werden können (statische Dateien werden unterstützt).

Nutzen / Mehrwert

• Konsistenter Look & Feel: Alle späteren PDF-Dokumente können auf derselben Basis aufbauen (gleiches Layout, gleiche Regeln für Seitenumbrüche, Tabellen etc.).
• Bessere Druckqualität: Spezielles Print-CSS sorgt dafür, dass Inhalte druckfreundlich auf Seiten verteilt werden (Paged Media).
• Zukunftssicherheit & Erweiterbarkeit: Weitere Module können später eigene Dokumentvorlagen anschließen, ohne das Rad neu zu erfinden.

Wichtig: Was ist ausdrücklich nicht enthalten?

• Noch keine fertigen Dokumente (z. B. Angebot/Rechnung) und keine Druck-Buttons in der Oberfläche.
• Keine automatische Ablage als Anhang oder Journaleinträge.

Kurz: Dieses Issue liefert das Fundament, damit das System künftig PDFs professionell und einheitlich erzeugen kann – die konkreten Dokumentvorlagen folgen in separaten Themen.

Auf den Admin-Seiten zur Azure AD Benutzerverwaltung gibt es künftig einen klar sichtbaren Einstieg zum Einladen neuer Benutzer.

Was ändert sich? - Auf beiden Admin-Seiten
- /admin/core/userprofile/ und
- /admin/core/userinvitation/
wird ein Button „Invite User“ ergänzt. - Ein Klick auf den Button führt immer direkt zur Einladungsseite: /admin/invite-users/. - Der Button wird an einer konsistenten Stelle platziert (z. B. im oberen Aktionsbereich), sodass er schnell auffindbar ist.

Nutzen für Anwender (Admins) - Die Benutzer-Einladung ist leichter zu finden und muss nicht mehr über manuelles Eingeben/Anpassen der URL aufgerufen werden. - Schnellere, einfachere Verwaltung von Azure AD Benutzern durch einen direkten, sichtbaren Einstieg.

Wichtig zu wissen - Es ändert sich nur die Oberfläche/Navigation: Die eigentliche Einladungsfunktion (Logik/Prozess) bleibt unverändert. - Es werden keine neuen Rollen oder Berechtigungen eingeführt; der Button ist nur dort sichtbar, wo man die Admin-Seiten ohnehin sehen darf.

Auf der Dozenten-Detailseite wird die Ansicht deutlich übersichtlicher gestaltet:

• Inhalte werden in Tabs organisiert: Statt vieler einzelner Karten in einer langen Ansicht werden die Bereiche Stammdaten, Standort-Zuordnungen, Bildungs- und Berufsinformationen und Notizen künftig als eigene Tabs dargestellt. Dadurch findet man Informationen schneller und die Seite wirkt aufgeräumter.

• Neuer Tab „Lehrveranstaltungen“: Es kommt ein zusätzlicher Tab „Lehrveranstaltungen“ hinzu. Dort sieht man in einer Tabelle alle Lehrveranstaltungen/Events, denen der aktuelle Dozent zugeordnet ist. Angezeigt werden genau:

• Event Name
• Event Type
• Status

• Zeit (von–bis)
  Zusätzlich kann man die Liste nach Type und Status filtern sowie nach Event Name suchen, um schneller die passende Veranstaltung zu finden.

• Zuletzt geöffneter Tab bleibt erhalten: Wenn man zwischen Tabs wechselt, merkt sich der Browser den zuletzt aktiven Tab. Beim erneuten Aufruf oder nach einem Reload landet man automatisch wieder in diesem Tab. Falls der gespeicherte Tab nicht verfügbar ist, wird als Fallback der erste Tab geöffnet.

Nutzen für Anwender: schnellere Orientierung in der Dozenten-Detailseite, weniger Scrollen, und ein direkter Überblick über zugeordnete Lehrveranstaltungen inkl. einfacher Filter- und Suchmöglichkeiten.

Zusammenfassung der Änderung: Verbesserte Protokollierung & Fehlerreporting

Mit diesem Issue wird die Anwendung besser nachvollziehbar und stabiler im Betrieb gemacht – durch lokale Logdateien mit automatischer Aufräumlogik sowie eine echte Sentry-Anbindung für die automatische Fehlererfassung in Produktivumgebungen.

1) Lokale Logdateien (täglich, automatisch bereinigt)

• Die Anwendung schreibt künftig Laufzeit- und Fehlermeldungen in ein lokales Log-Verzeichnis: ./logs (im Projektpfad).
• Es wird pro Tag genau eine Logdatei erzeugt, z. B. app-2026-02-05.log.
• Die Logdateien werden 7 Tage aufbewahrt; ältere Dateien werden automatisch gelöscht.
• Es werden mindestens die Log-Stufen DEBUG, INFO, WARNING, ERROR sauber unterstützt.

Nutzen für Anwender/Betrieb: - Probleme lassen sich schneller eingrenzen, weil Ereignisse und Fehler nachvollziehbar pro Tag dokumentiert sind. - Kein “vollgelaufener Server” durch endlos wachsende Log-Dateien, da automatisch aufgeräumt wird. - Logs sind zentral und konsistent – sowohl für Framework-Meldungen als auch für App-spezifische Einträge.

2) Sentry-Integration (aktiv nur wenn konfiguriert)

• Es wird eine produktionsfähige Sentry-Integration eingebaut.
• Sentry wird nur aktiviert, wenn die Umgebungsvariable SENTRY_DSN gesetzt ist.
• Ist SENTRY_DSN nicht gesetzt oder leer, läuft die Anwendung ganz normal weiter – ohne Sentry.
• Erfasst werden:
• Unhandled Exceptions (nicht abgefangene Fehler)
• Django-Fehler

Nutzen für Anwender/Betrieb: - Kritische Fehler werden automatisch gemeldet, statt nur „irgendwo“ aufzutauchen. - Schnellere Reaktionszeiten bei Produktionsproblemen, da Fehler zentral sichtbar und auswertbar sind. - Keine Veränderung des Fehlerverhaltens: Fehler werden nicht “verschluckt”, sondern zusätzlich gemeldet.

Hinweis zu optionalen Punkten

Optionale Erweiterungen wie Request-ID in Logs oder User-Kontext in Sentry sind als „nice to have“ vorgesehen, werden aber nur umgesetzt, wenn sie ohne größeren Umbau möglich sind.

Änderung: Support-Bereich in Phönix (AGIRA) integriert

In Phönix wird ein neuer Menüpunkt „Support“ in der oberen Navigation hinzugefügt. Darüber gelangen Anwender auf eine neue Seite /support, auf der das externe Kundensupport-Portal AGIRA direkt innerhalb von Phönix angezeigt wird.

Was genau ändert sich?

• Neuer Navigationspunkt „Support“ (inkl. Icon) in der Top-/Header-Leiste.
• Neue Support-Seite (/support), die das AGIRA-Kundenportal als eingebettete Ansicht (IFrame) darstellt.
• Die Verknüpfung zum Portal wird nicht fest im Code hinterlegt, sondern aus der Systemkonfiguration (ENV-Variablen) zusammengesetzt.

Verhalten bei fehlender Konfiguration

Wenn das Support-Portal in einer Umgebung nicht eingerichtet ist (z. B. fehlende Konfigurationswerte), wird kein Portal eingebettet. Stattdessen sehen Nutzer einen Hinweis, dass das Customer Portal derzeit nicht aktiviert ist.

Nutzen für Anwender

• Schneller Zugang zum Support direkt aus Phönix, ohne separate Links oder Systemwechsel.
• Einheitlicher Einstiegspunkt über die Navigation („Support“) – leichter auffindbar und konsistent im Alltag.

Mit diesem Issue wird in der UserUI eine vollständige Modulverwaltung eingeführt. Anwender können Module künftig direkt in der Oberfläche anzeigen, suchen/filtern, anlegen, bearbeiten und löschen – jeweils ausschließlich innerhalb des aktuell global ausgewählten Mandanten (Tenant).

Was ändert sich für Anwender?

1) Neuer Menüpunkt für die Modulverwaltung - In der Hauptnavigation gibt es eine neue Kategorie „Modulverwaltung“ - Darunter den Menüpunkt „Module“, der zur Modulliste führt

2) Modulliste mit Suche, Filtern und Paging - Es gibt eine Listenansicht aller Module des aktuell ausgewählten Mandanten - Funktionen in der Liste: - Freitextsuche - Filter (u. a. Fakultät und SPO) - Sortierung nach Projektstandard - Paging: 25 Einträge pro Seite - Wichtig: In den Filtern Fakultät und SPO werden nur Werte des aktuell ausgewählten Mandanten angeboten - Wenn der Mandant in der globalen Auswahl gewechselt wird, aktualisiert sich die Liste entsprechend und zeigt die Module des neuen Mandanten

3) Detailseite pro Modul: Anzeigen und Bearbeiten - Für ein einzelnes Modul gibt es eine Detailseite mit zwei Modi: - Ansicht (View Mode): Felder nur lesen - Bearbeiten (Edit Mode): Felder ändern und speichern - Validierungen und Fehlermeldungen erfolgen nach dem UI-Standard - Welche Felder angezeigt/bearbeitet werden, entspricht dem Umfang wie in der Admin UI

4) Module anlegen und löschen - In der UI kann ein neues Modul angelegt werden - Das Modul wird automatisch dem aktuell ausgewählten Mandanten zugeordnet (der Mandant kann nicht „umgangen“ oder manipuliert werden) - Module können gelöscht werden, inklusive Bestätigungsdialog - Nach dem Löschen geht es zurück zur Liste

Nutzen / Mehrwert

• Komplette Modulpflege ohne Admin-Oberfläche: Module können direkt in der UserUI verwaltet werden.
• Schnelleres Finden durch Suche/Filter + Paging: auch bei vielen Modulen bleibt die Liste übersichtlich.
• Saubere Datenisolation: Anwender sehen und bearbeiten nur die Daten des aktuell gewählten Mandanten; auch direkte URL-Aufrufe auf fremde Daten werden serverseitig blockiert.

In der User-Oberfläche wird die Entität „equipment“ vollständig integriert, sodass Sie „equipment“-Einträge künftig direkt in der Anwendung verwalten können – ohne Umweg über technische Admin-Oberflächen.

Was ändert sich für Sie?

• Neuer Menübereich „Settings“
• In der Navigation gibt es eine neue Kategorie „Settings“.

• Darunter finden Sie einen neuen Eintrag „equipment“, der zur Übersicht führt.

• Übersichtsseite (Liste) für „equipment“

• Anzeige aller „equipment“-Einträge in einer Tabellenansicht mit den im System vorgesehenen Spalten.
• Suchen & Filtern:
  • Freitextsuche (z. B. um Einträge schnell zu finden)
  • Zusätzliche Filtermöglichkeiten passend zu den vorhandenen „equipment“-Feldern
• Sortieren & Blättern (Paging) wie in anderen Listenansichten.

• Pro Zeile stehen Aktionen zur Verfügung: Ansehen/Details, Bearbeiten und ggf. Löschen (wenn erlaubt).

• Detailseite für „equipment“ (Ansehen & Bearbeiten)

• Zwei Modi:
  • Ansicht: Daten werden nur angezeigt
  • Bearbeiten: Daten können geändert und gespeichert werden

• Unterstützt:

  • Neu anlegen (Create)
  • Ansehen (Read)
  • Bearbeiten (Update)
  • Löschen (Delete – mit Schutzmechanismus, siehe unten)

• Sicheres Löschen (Löschschutz)

• Ein „equipment“-Eintrag kann nicht gelöscht werden, wenn er noch von anderen Daten im System verwendet wird.
• Das wird sowohl in der Oberfläche nachvollziehbar gemacht (z. B. deaktiviert oder mit verständlicher Meldung) als auch serverseitig zuverlässig verhindert.

Nutzen / Mehrwert

• Sie können „equipment“ zentral und konsistent in der normalen UserUI pflegen (schneller, weniger fehleranfällig).
• Durch Suche, Filter und Sortierung finden Sie Einträge deutlich schneller.
• Der Löschschutz verhindert versehentliche Datenverluste oder inkonsistente Daten, wenn „equipment“ noch in Verwendung ist.
• Die angezeigten Felder und Filter entsprechen den bereits definierten „equipment“-Einstellungen, wodurch die UI einheitlich bleibt.

Zusammenfassung der Änderung: „Abschlüsse“ in der User-Oberfläche verwalten (inkl. Anlegen, Bearbeiten, Löschen)

In der UserUI wird die Entität „Abschlüsse“ vollständig integriert, sodass Anwender Abschlüsse künftig direkt in der Oberfläche verwalten können – ähnlich wie bisher in der Admin-Ansicht, aber nutzerfreundlich in der UserUI.

Was ändert sich konkret?

• Neuer Menüpunkt in der Navigation
• In der Hauptnavigation gibt es eine neue Kategorie „Modulverwaltung“

• Darin einen neuen Eintrag „Abschlüsse“, der zur Übersicht führt

• Übersichtsliste mit Filtern und Suche

• Es gibt eine Listenansicht aller Abschlüsse als Tabelle
• Mit Filtermöglichkeiten und Freitextsuche, damit Einträge schneller gefunden werden können

• Wichtig: Es werden nur Abschlüsse des aktuell ausgewählten Mandanten angezeigt (Mandantentrennung)

• Detailansicht mit Anzeige- und Bearbeitungsmodus

• Jeder Abschluss hat eine Detailseite
• Dort kann man zwischen Anzeigen (nur lesen) und Bearbeiten (ändern & speichern) wechseln

• Änderungen werden dauerhaft gespeichert

• Neuanlage (Create) von Abschlüssen

• Abschlüsse können neu angelegt werden
• Bei der Mandantenauswahl werden nur Mandanten angeboten, denen der Benutzer angehört

• Gehört ein Benutzer genau einem Mandanten an, ist dieser automatisch vorausgewählt

• Löschen (Delete) mit Schutz bei Abhängigkeiten

• Abschlüsse können gelöscht werden, sofern keine abhängigen/verknüpften Daten existieren

• Wenn ein Abschluss noch referenziert wird, wird das Löschen verhindert (statt ungewollt Datenbeziehungen zu beschädigen)

• Felder/Spalten entsprechen der Admin-Ansicht

• Welche Spalten in der Liste und welche Felder im Detail angezeigt werden, orientiert sich an der ModelAdmin-Konfiguration (damit die Darstellung konsistent bleibt)

Nutzen / Mehrwert für Anwender

• Schneller Zugriff: Abschlüsse sind direkt in der UserUI erreichbar, ohne Umwege über Admin-Bereiche.
• Bessere Übersicht: Filtern und Suchen erleichtert das Finden von Einträgen deutlich.
• Mehr Sicherheit: Mandantentrennung verhindert, dass Daten aus anderen Mandanten angezeigt oder versehentlich bearbeitet werden.
• Weniger Fehler beim Löschen: Das System verhindert das Entfernen von Abschlüssen, die noch in Verwendung sind.

In der UserUI wird die Entität „faculty“ vollständig in die Oberfläche integriert, sodass sie künftig direkt in der Anwendung verwaltet werden kann – ohne Umweg über eine separate Admin-Oberfläche.

Was wird neu möglich sein?

Unter Settings → faculty steht eine neue Verwaltungsseite zur Verfügung mit allen Standardaktionen:

• Übersicht / Liste
• Anzeige aller „faculty“-Einträge als Tabelle
• Filtern und Suchen innerhalb der Liste

• Es werden ausschließlich die Einträge angezeigt, die zum aktuell global ausgewählten Mandanten gehören (Mandantentrennung ist fest umgesetzt, nicht nur optisch).

• Details ansehen und bearbeiten

• Detailansicht mit einem Anzeigemodus (nur lesen)
• Wechsel in den Bearbeitungsmodus, Speichern aktualisiert den Datensatz

• Validierungen und Fehlermeldungen entsprechen den bekannten UI-Mustern.

• Neuanlage (Create)

• Neue „faculty“-Einträge können angelegt werden

• Bei der Mandantenauswahl sind nur Mandanten auswählbar, denen der eingeloggte Nutzer auch angehört (keine versehentliche Anlage im falschen Mandanten).

• Löschen (Delete)

• Einträge können gelöscht werden
• Wichtig: Wenn ein „faculty“-Eintrag noch von anderen Daten verwendet/referenziert wird, wird das Löschen blockiert und es erscheint eine verständliche Fehlermeldung, damit keine inkonsistenten Daten entstehen.

Welche Felder sehe ich in Liste/Detail/Maske?

Die angezeigten und bearbeitbaren Felder werden 1:1 aus der bestehenden ModelAdmin-Konfiguration übernommen (keine neuen Felder, keine abweichende Feldlogik). Dadurch entspricht die Darstellung dem, was bereits im System definiert ist.

Nutzen für Anwender

• „faculty“ kann schneller und konsistenter im normalen Arbeits-UI gepflegt werden.
• Bessere Orientierung durch Suche/Filter in der Liste.
• Mandantensicherheit: Man sieht nur die Daten des gewählten Mandanten und kann nur in berechtigten Mandanten anlegen.
• Mehr Datensicherheit durch Schutz vor Löschen, wenn der Eintrag noch genutzt wird.

Zusammenfassung der Änderung (aus Anwendersicht)

Im Dozenten-/Lehrendenprofil (TenantTeacher) wird eine neue Funktion ergänzt, um Module automatisch aus dem UIS zu übernehmen. Damit können vorhandene historische Prüfungsdaten genutzt werden, um fehlende Verknüpfungen zwischen Lehrenden und Modulen in Phönix nachzutragen – ohne manuelle Pflege.

Was wird neu möglich?

1) Button im Lehrenden-Detail: „Module aus UIS übernehmen“

Im Detail eines Lehrenden gibt es einen neuen Button (z. B. „Module aus UIS übernehmen“).
Nach Klick werden die im UIS bekannten Prüfungen dieses Lehrenden geprüft und daraus automatisch fehlende Modul-Zuordnungen in Phönix angelegt.

Die Oberfläche zeigt danach eine einfache Erfolgs- oder Fehlermeldung.

2) Initiale Befüllung für einen ganzen Tenant

Zusätzlich gibt es eine Funktion im Backend, die denselben Abgleich für alle Lehrenden eines Tenants durchführen kann (z. B. für eine Erstbefüllung nach Einführung der Funktion).

Wie verhält sich das System dabei?

• Es werden nur fehlende Zuordnungen ergänzt (Lehrender ↔ Modul).
  Bereits vorhandene Zuordnungen bleiben unverändert.
• Keine Duplikate: Wiederholtes Ausführen erzeugt keine doppelten Einträge.
• Bei neuen Zuordnungen wird das Feld „letzte Lehre“ befüllt:
• Es wird das neueste Semester verwendet, in dem zu diesem Modul eine Prüfung gefunden wurde.
• Falls das Semester aus den UIS-Daten nicht eindeutig ermittelt werden kann, wird die Zuordnung trotzdem angelegt – „letzte Lehre“ bleibt dann leer.

Nutzen / Mehrwert

• Weniger manuelle Pflege: Modul-Zuordnungen können schnell aus verlässlichen UIS-Historien übernommen werden.
• Bessere Datenbasis: Das Feld „letzte Lehre“ ist bei neu angelegten Zuordnungen direkt sinnvoll vorbelegt (wenn die Daten vorhanden sind).
• Sicher bei Wiederholung: Die Funktion kann bei Bedarf mehrfach ausgeführt werden, ohne Daten zu „vermüllen“ oder bestehende Einträge zu verändern.

In der UserUI wird die Entität „studyprograms“ vollständig integriert, sodass Sie Studienprogramme künftig direkt in der Oberfläche anzeigen, anlegen, bearbeiten und (wenn möglich) löschen können – ohne auf die Admin-Ansicht ausweichen zu müssen.

Was ändert sich für Sie?

• Neuer Menüpunkt: Unter „Settings“ erscheint ein neuer Eintrag „studyprograms“, der zur Übersicht führt.
• Übersichtsliste mit Suche & Filtern:
  Die Studienprogramme werden in einer Liste angezeigt, inklusive Suchfeld und Filtermöglichkeiten. Angezeigt werden dabei die gleichen Informationen/Spalten, die bisher auch in der bestehenden Admin-Ansicht vorgesehen sind.
• Mandantenbezogene Anzeige:
  In der Liste sehen Sie nur die Studienprogramme des aktuell global ausgewählten Mandanten. Das sorgt für klare Trennung und verhindert Verwechslungen zwischen Mandanten.
• Detailansicht mit Anzeigemodus und Bearbeitungsmodus:
  Ein Studienprogramm kann geöffnet und zunächst angesehen werden; bei Bedarf können die Daten im Edit-Modus geändert werden (Felder entsprechend der bisherigen Admin-Definition).
• Neuanlage mit eingeschränkter Mandantenauswahl:
  Beim Anlegen eines Studienprogramms können Sie beim Feld Mandant nur Mandanten auswählen, denen Sie selbst zugeordnet sind. Diese Regel wird auch im Hintergrund geprüft, sodass keine „falschen“ Zuordnungen möglich sind.
• Sicheres Löschen:
  Ein Studienprogramm kann nicht gelöscht werden, wenn es noch von anderen Daten verwendet wird. In diesem Fall bleibt der Datensatz bestehen und die Oberfläche zeigt eine verständliche Fehlermeldung, warum das Löschen nicht möglich ist.

Nutzen / Mehrwert

• Einheitliche Pflege in der UserUI (kein Wechsel in andere Oberflächen nötig).
• Bessere Übersicht durch Suche und Filter.
• Mehr Sicherheit in Mandantenumgebungen, weil nur relevante Daten angezeigt werden und Zuweisungen beim Anlegen korrekt eingeschränkt sind.
• Schutz vor Datenfehlern, da das Löschen verhindert wird, wenn Abhängigkeiten bestehen.

In der Dozenten-/Lehrkraft-Detailansicht (TenantTeacher DetailView) werden die Stammdaten um zusätzliche Informationen erweitert, damit relevante Angaben zentral erfasst und später zuverlässig wieder aufgerufen werden können.

Was ändert sich für Anwender?

1) Erweiterung im Tab „Bildungs- und Berufsinformationen“

• Es kommt ein neues Feld hinzu: „Hauptbeschäftigt bei“
  → Hier kann hinterlegt werden, bei welchem Arbeitgeber die Lehrkraft hauptsächlich beschäftigt ist.

Nutzen: Schnellere Orientierung und vollständigere Dozentenprofile, z. B. für interne Abstimmungen oder Verwaltungsprozesse.

2) Neuer Tab „Steuerrechtliche Angaben“

Ein neuer Tab „Steuerrechtliche Angaben“ wird ergänzt mit folgenden Eingabefeldern: - Finanzamt Name - Finanzamt Strasse - Finanzamt PLZ und Ort - Steuernummer

Nutzen: Steuerrelevante Informationen können direkt am Dozentenprofil gepflegt werden, ohne auf externe Notizen oder separate Dokumentationen angewiesen zu sein.

3) Neuer Tab „Bankverbindung“

Ein weiterer neuer Tab „Bankverbindung“ wird ergänzt mit: - Kreditinstitut - Kontoinhaber - IBAN - BIC

Zusätzlich gilt: „Kontoinhaber“ wird beim ersten Befüllen automatisch mit dem Namen der Lehrkraft vorbelegt – aber nur, wenn das Feld noch leer ist. Spätere Namensänderungen aktualisieren den Kontoinhaber nicht automatisch.

Nutzen: Bankdaten sind strukturiert am Profil verfügbar (z. B. für Auszahlungen/Abrechnungen), mit weniger manueller Eingabe durch die Vorbelegung.

Verhalten / Einschränkungen

• Alle neuen Felder sind optional.
• Eingaben werden gespeichert und beim erneuten Öffnen der Detailansicht korrekt wieder geladen.

Änderung: Admin-Seite „CoursePeriode“ lädt wieder – fehlerhafte Datumswerte werden abgefangen

Beim Öffnen der Verwaltungsseite CoursePeriode im Admin-Bereich (/admin/core/courseperiode/) kam es bisher zu einem Serverfehler. Ursache war mindestens ein Datensatz mit einem ungültigen Datumswert (Jahr -1). Dadurch ist nicht nur dieser einzelne Eintrag problematisch gewesen, sondern die gesamte Liste konnte nicht mehr angezeigt werden.

Was wird geändert? - Ungültige Datumsangaben in vorhandenen CoursePeriode-Datensätzen werden bereinigt, indem sie auf „leer“ (NULL) gesetzt werden. - Die Admin-Listenansicht wird so angepasst, dass sie auch bei fehlerhaften/ungewöhnlichen Altdaten stabil bleibt und nicht mehr komplett abstürzt.

Nutzen für Anwender - Die CoursePeriode-Liste im Admin ist wieder zuverlässig aufrufbar. - Einzelne fehlerhafte Datensätze blockieren nicht mehr die Arbeit im Admin. - Dadurch wird die Verwaltung und Kontrolle der Daten schneller und weniger fehleranfällig, insbesondere bei historischen oder importierten Datensätzen.

Zusammenfassung der Änderung (für Anwender/Admins)

Admins können künftig Benutzer:innen direkt aus dem zentralen Microsoft Entra ID (Azure AD) der Mitarbeitenden in der Anwendung suchen, auswählen und einladen. Dabei werden die im Azure AD vorhandenen Informationen genutzt (z. B. Benutzername/UPN, Name, E-Mail), sodass diese nicht mehr manuell in der Anwendung nacherfasst werden müssen.

Was ändert sich konkret?

• Suche & Auswahl in Entra ID (Azure AD):
  Im Admin-Bereich gibt es eine Funktion, um Mitarbeitenden-Accounts im zentralen Entra ID per Textsuche zu finden und auszuwählen (z. B. nach UPN/Benutzername, optional Name/E-Mail).

• Automatische Tenant-Zuordnung über die UPN-Domain:
  Beim Einladen wird der passende Tenant automatisch ermittelt – basierend auf der Domain im UPN (z. B. vorname.nachname@firma.de).
  Wenn keine passende Domain zu einem Tenant hinterlegt ist, wird die Einladung nicht durchgeführt (damit der User nicht “falsch” zugeordnet wird).

• Einladung per E-Mail:
  Nach erfolgreicher Auswahl wird der User in der Anwendung als „eingeladen“ registriert und erhält eine Einladungs-E-Mail mit dem Link zur SSO-Anmeldung. Dafür wird ein neues HTML-Mail-Template verwendet.

• Kein doppelter Benutzer beim ersten Login:
  Wenn ein eingeladener User sich das erste Mal per SSO anmeldet, wird er zuverlässig dem bereits eingeladenen Benutzerkonto zugeordnet (Matching über den UPN).
  Dadurch entstehen keine doppelten Accounts durch das automatische Anlegen (Auto‑Provisioning).

• Spezialfall: User existiert lokal bereits mit gleichem UPN:
  Ist der User bereits in der Anwendung vorhanden, wird nur verknüpft – es wird keine neue Einladung verschickt.

Wichtiger Hinweis zur Entra/Graph-Anbindung

Für Suche und E-Mail-Versand wird nicht eine tenant-spezifische Graph-Konfiguration (z. B. aus Studierenden-/Dozierenden-Setups) verwendet, sondern ausschließlich die zentralen Graph-API Zugangsdaten aus der Umgebungskonfiguration (env). Das stellt sicher, dass wirklich die Mitarbeitenden-Verzeichnisstruktur genutzt wird.

Nutzen / Mehrwert

• Weniger manuelle Eingaben: Name/UPN/E-Mail müssen nicht doppelt gepflegt werden.
• Schnelleres, konsistenteres Onboarding: Einladen direkt aus dem Verzeichnis, inkl. automatischer Zuordnung zum richtigen Tenant.
• Weniger Supportfälle: Keine doppelten Benutzerkonten beim ersten Login durch sauberes Matching.

Es wird eine neue Funktion im Tenant-Admin Backend bereitgestellt, mit der Kursperioden/Semester aus dem zentralen System UIS nach Phönix übernommen werden können.

Was ändert sich?

• Der Tenant-Admin kann eine Synchronisation der Kursperioden/Semester starten.
• Phönix lädt dafür die Kursperioden aus UIS und legt sie in der Phönix-Datenbasis als Kursperioden an.
• Dabei wird je Kursperiode geprüft, ob sie in Phönix bereits existiert (Vergleich über die Sortierposition).
• Fehlt sie: wird sie neu angelegt (inkl. Name/Bezeichnung und Zeitraum „von/bis“).
• Ist sie vorhanden: passiert nichts (bestehende Einträge werden nicht geändert).

Nutzen / Mehrwert für Anwender

• Konsistente Kursperioden/Semester in Phönix: Die in UIS gepflegten Semester stehen in Phönix zur Verfügung, ohne dass sie manuell nachgebaut werden müssen.
• Keine doppelten Einträge: Die Synchronisation kann jederzeit erneut ausgeführt werden, ohne Duplikate zu erzeugen.
• Sicheres Verhalten bei Fehlern: Wenn UIS nicht erreichbar ist oder ein Fehler auftritt, wird das sauber behandelt und es entstehen keine „halb angelegten“ oder inkonsistenten Daten.

Wichtig zu wissen

• Die Synchronisation ist nur zum Ergänzen gedacht: Bereits vorhandene Kursperioden werden nicht aktualisiert, selbst wenn sich Daten in UIS geändert haben.

Änderung im Admin: Tenant kann wieder ohne Serverfehler gespeichert werden

Beim Bearbeiten eines Tenants im Admin-Bereich kam es bisher beim Speichern zu einem 500-Serverfehler. Ursache war, dass das Admin-Formular beim Absenden zu viele Formularfelder/Parameter übermittelt hat und damit ein Sicherheits-/Konfigurationslimit überschritten wurde. Ergebnis: Änderungen konnten nicht gespeichert werden (teilweise sogar dann nicht, wenn man „nur speichern“ klickt).

Was wird geändert?

• Das Tenant-Änderungsformular im Admin wird so angepasst, dass beim Speichern nicht mehr „zu viele Felder“ übertragen werden.
• Falls notwendig, wird zusätzlich die zugrunde liegende Grenze für die maximal erlaubte Anzahl an Formularfeldern passend konfiguriert – inklusive nachvollziehbarer Dokumentation, warum das nötig ist.

Nutzen für Anwender

• Tenant-Daten lassen sich wieder zuverlässig im Admin speichern, ohne Absturz/Serverfehler.
• Weniger Unterbrechungen im Administrationsablauf und stabileres Verhalten beim Arbeiten im Backend.
• Die Ursache ist dokumentiert, damit das Problem nicht bei zukünftigen Änderungen erneut auftritt.

In diesem Release wird die Benutzerverwaltung im Admin-Bereich korrigiert und stabiler gemacht:

• Einladungs-/Benutzerverwaltungsseite im Admin wieder erreichbar: Ein Aufruf wie /admin/invite-users/ führte bislang zu einer 404 “Seite nicht gefunden”-Meldung. Das wird behoben, sodass Administratoren die entsprechende Funktion wieder nutzen können.

• Suche nach Azure AD Benutzern funktioniert wieder zuverlässig: Beim Suchen nach Nutzern aus Azure Active Directory trat aktuell ein Fehler auf:
  „Failed to search Azure AD … 400 - Sorting not supported for current query.“
  Dieser Fehler wird behoben, sodass die Azure-AD-Suche wieder ohne Abbruch durchläuft.

Nutzen für Anwender (Admins): Benutzer lassen sich wieder wie erwartet über den Admin-Bereich finden und verwalten bzw. einladen – ohne „Seite nicht gefunden“-Fehler und ohne Abbrüche bei der Azure-AD-Suche.