Phönix

Ein Vorplanungstermin hat jetzt ein Pflichtfeld „Semester“. Es nutzt dieselben Kursperioden wie die Zielperiode der Studiengruppen. Im Formular stehen Semester und Standort vorn; die Studiengruppen-Auswahl zeigt danach nur noch Gruppen des Mandanten mit diesem Semester als Zielperiode am gewählten Standort. Die Gruppen sind eindeutig beschriftet, nach Abschluss und Studiengang gruppiert, nach Fachsemester sortiert und durchsuchbar. Unpassende Auswahlen werden bei einem Wechsel mit Hinweis entfernt und beim Speichern serverseitig abgelehnt. Liste und Kalender lassen sich nach Semester filtern, die Liste zeigt eine Spalte „Semester“. Die APIs liefern je Termin ein Feld semester und filtern optional danach. Bestandstermine haben das Semester per Migration erhalten, soweit es ableitbar war; die übrigen listet report_preplanned_session_semesters zur Nachbearbeitung.

In der Studiengruppen-Übersicht werden gesetzte Filter künftig im Browser gespeichert.
Wenn Sie die Übersicht später erneut öffnen, werden die zuletzt verwendeten Filter automatisch wiederhergestellt, sofern keine anderen Filter über den geöffneten Link vorgegeben sind.
Dadurch müssen häufig genutzte Filter nicht bei jedem Seitenaufruf erneut eingestellt werden.
Wenn ein Link bereits eigene Filterangaben enthält, werden diese verwendet und nicht durch gespeicherte Einstellungen ersetzt.
Beim Zurücksetzen der Filter wird auch der gespeicherte Filterzustand entfernt, damit keine alten Werte unbeabsichtigt wieder erscheinen.
Die bestehende Mandantenauswahl bleibt dabei unverändert wirksam.
Die Änderung betrifft ausschließlich die Studiengruppen-Übersicht und hat keine Auswirkungen auf andere Listenansichten.

In der Erfassung von Vorplanungsterminen ist die Zuordnung zu einer Studiengruppe künftig nicht mehr zwingend erforderlich. Stattdessen ist der Name des Termins das zentrale Pflichtfeld und wird für Listen, Detailansichten, Kalenderanzeigen und weitere Hinweise verwendet. Dadurch können auch allgemeine Veranstaltungen oder Termine ohne festen Studiengruppenbezug sauber angelegt, bearbeitet und angezeigt werden. Wird weiterhin eine Studiengruppe ausgewählt und kein eigener Name eingetragen, wird der Name automatisch aus der ausgewählten Studiengruppe übernommen. Bestehende Abläufe mit Studiengruppen bleiben erhalten und funktionieren wie bisher. Auch Termine ohne Studiengruppe bleiben für berechtigte Nutzer sichtbar und können weiterbearbeitet werden. Beim Kopieren eines Vorplanungstermins werden relevante Angaben wie Name und Veranstaltungsart nun ebenfalls übernommen.

In den Listenansichten mit Suche, Filtern, Sortierung und Seitenwechsel bleiben Ihre gewählten Einstellungen künftig erhalten, auch wenn Sie zwischendurch einen Eintrag ansehen, bearbeiten oder löschen. Wenn Sie danach zur Liste zurückkehren, wird wieder genau dieselbe gefilterte Ansicht angezeigt – inklusive Suchbegriff, ausgewählten Filtern, Sortierung und der aktuellen Seite. Auch nach dem Speichern oder Löschen werden Sie zurück in die Liste geführt, ohne dass Ihre Filter zurückgesetzt werden. Das gilt konsistent für die relevanten Verwaltungslisten in der UserUI (z. B. Module, Equipment und Studyprograms). Dadurch entfällt das erneute Setzen von Filtern nach einzelnen Arbeitsschritten, und Sie können mehrere Datensätze nacheinander effizienter bearbeiten.

Im Dozentenportal können künftig Vorplanungstermine angezeigt werden, denen ein Dozent in einer Hochschule zugeordnet ist.
Die Zuordnung erfolgt hochschulbezogen, sodass Dozenten nur die Termine sehen, die zu ihrer jeweiligen Hochschule und eigenen Zuordnung gehören.
Zu einem Termin werden die relevanten Informationen wie Zeitraum, Standort, Lehrstandort, Räume, Module, Studiengruppen und weitere beteiligte Dozenten angezeigt.
Interne Notizen sowie E-Mail-Adressen oder andere sensible Daten anderer Dozenten werden dabei nicht weitergegeben.
Die Anzeige kann pro Hochschule im Admin-Bereich separat freigeschaltet werden und ist standardmäßig deaktiviert.
Ist die Funktion nicht freigeschaltet, werden im Dozentenportal keine Vorplanungstermine ausgegeben.
Damit erhalten Dozenten eine klare Übersicht darüber, wann und wo sie bereits vorgeplant sind, ohne dass zusätzliche manuelle Listen oder Abstimmungen nötig sind.

Vorplanungstermine haben nur noch ein optionales Mehrfachauswahl-Feld „Räume“; das bisherige Feld „Raum“ entfällt in Formularen und Admin. Wählbar sind nur Räume, die der aktive Mandant laut Raumverwaltung buchen darf (eigener oder hochschulübergreifender Raum) und die am Standort des Termins liegen. Beim Standortwechsel lädt die Raumliste neu, nicht passende Räume werden mit Hinweis entfernt, und fremde Räume werden auch bei manipulierten Anfragen abgelehnt. Bestehende Einzelräume wurden per Migration in „Räume“ übernommen. Räume, die die neue Regel verletzen, werden nicht gelöscht, sondern bei der Migration bzw. mit python manage.py report_preplanned_session_rooms zur fachlichen Prüfung gelistet.

Der automatische Modul-Sync in der Studiengruppen-Detailansicht hat bei Nutzern mit mehreren Mandanten den gewählten Mandanten nicht erkannt und deshalb „Auswahl ungültig“ gemeldet. Das ist behoben (PR #482). Der Ladeindikator endet immer, „Aktualisieren“ stößt den Sync erneut an. Folgekorrektur (PR #484): Danach scheiterte der Sync beim lokalen Speichern der Module und zeigte fälschlich „UIS ist derzeit nicht erreichbar“. Das Speichern ist jetzt robust: Konflikte mit manuell angelegten Modulen überspringen nur das betroffene Modul, und bei einem Fehler bleiben die bisherigen Module erhalten. Die Modul-ID aus UIS passt jetzt auch bei großen Werten in die Datenbank (Migration 0106). Tritt doch ein interner Fehler auf, nennt der Hinweis jetzt dessen Art statt UIS fälschlich als Ursache anzugeben.

Prüfungsformen wie „Klausur“, „Hausarbeit“ oder „Portfolio“ werden künftig als Stammdaten der Hochschule pro Mandant gepflegt und nicht mehr einzeln je Studienprüfungsordnung angelegt.
Beim Erstellen einer Prüfungsform entfällt daher das Pflichtfeld „Studienprüfungsordnung“; pro Mandant kann derselbe Name nur einmal verwendet werden.
Welche Prüfungsform für ein bestimmtes Modul gilt, wird nun direkt im Studienverlaufsplan bei der jeweiligen Modulzuordnung einer SPO hinterlegt.
Dadurch kann dasselbe Modul in unterschiedlichen SPOs mit unterschiedlichen Prüfungsformen geführt werden, ohne das Modul selbst zu verändern.
In den Listen-, Detail- und Admin-Ansichten der Prüfungsformen wird keine SPO mehr angezeigt; die Detailansicht zeigt stattdessen, in wie vielen Studienverlaufsplan-Einträgen die Prüfungsform verwendet wird.
Bereits vorhandene doppelte Prüfungsformen werden bei der Umstellung pro Mandant zusammengeführt, sodass die Bestandsdaten ohne manuelle Nacharbeit bereinigt werden.
Verwendete Prüfungsformen können nicht gelöscht, aber weiterhin deaktiviert werden; dadurch bleiben bestehende Studienverlaufspläne nachvollziehbar und geschützt.

In Phoenix können für die Uni Seeburg künftig feste Prüfungsformen gemäß Prüfungsordnung (SPO) zentral hinterlegt werden – inklusive Angaben wie „erlaubte Hilfsmittel“ und einer terminbezogenen Information. Diese Prüfungsinformationen werden in Dozenten-Kontexten nur noch angezeigt und können dort nicht mehr geändert werden. In Dozenten-Anfragen und bei der Annahme von Lehraufträgen sind die Prüfungsform-Details damit standardisiert sichtbar, ohne dass Dozenten sie erneut eingeben müssen. Dadurch wird sichergestellt, dass überall die gleichen, verbindlichen Angaben verwendet werden und manuelle Abweichungen vermieden werden. Die Pflege dieser Prüfungsformen ist für angemeldete Nutzer möglich, jedoch immer nur innerhalb des jeweils ausgewählten Mandanten. So bleiben Daten sauber getrennt und Prüfungsinformationen sind pro Hochschule eindeutig zugeordnet.

Phönix bietet jetzt den Endpunkt GET /api/student-portal/preplanned-sessions/ (Service-zu-Service mit X-API-Key/X-API-Secret). Er liefert zu Hochschule, Studiengang, Abschluss und Fachsemester genau die Vorplanungstermine der passenden Studiengruppen, jeden Termin nur einmal und mit Kennzeichen „Vorplanung“. Das Portal übergibt das aktuelle Fachsemester; Phönix leitet daraus die Fachsemester der nächsten Perioden ab (Alternative: Zielperiode + Fachsemester direkt). Die Auslieferung wird pro Hochschule im Admin eingeschaltet (Tenant → Studierendenportal). Die Doku für das Portal (#1272) liegt in docs/WEBAPI_STUDENT_PORTAL_PREPLANNED_SESSIONS.md, die OpenAPI-Spezifikation in docs/openapi/phoenix-api.yaml.

In der Detailansicht einer Studiengruppe können Vorplanungstermine bzw. Präsenzblöcke künftig direkt einzelnen Modulen zugeordnet werden.
Dies ist sowohl für reguläre Module im Studienverlauf als auch für flexible Module ohne Fachsemester möglich.
Unter jedem Modul werden die zugeordneten Termine angezeigt und können dort hinzugefügt oder wieder entfernt werden.
Die Anzeige macht erkennbar, zu welchem Standort ein Termin gehört, sodass standortbezogene Planungen übersichtlicher nachvollziehbar sind.
Beim Zuweisen wird verhindert, dass derselbe Vorplanungstermin einem Modul mehrfach zugeordnet wird; bei bereits belegten Kombinationen erfolgt ein entsprechender Hinweis.
Gespeicherte Zuordnungen bleiben auch nach erneutem Laden oder Synchronisieren erhalten.
Damit wird die Vorplanung in der Studiengruppenansicht wieder vollständiger abgebildet und die spätere Weiterverarbeitung standortbezogener Termine besser vorbereitet.

Die Uhrzeiten der Event-Templates eines didaktischen Modells sind jetzt im Editor auch nachträglich änderbar: die Detailseite hat je Event-Template einen Bearbeiten-Button, der das bestehende Modal mit den gespeicherten Werten vorbefüllt und über einen neuen Edit-Endpoint speichert. Bisher gab es nur Anlegen und Löschen, weshalb einmal angelegte Modell-Events auf den Feld-Defaults 09:00–16:00 stehen blieben und diese beim Zuweisen des Modells an einen Course an die erzeugten Events weitergereicht wurden. Zusätzlich fallen leere Uhrzeit-Angaben nicht mehr stillschweigend auf 09:00/16:00 zurück, sondern werden mit einer Fehlermeldung abgewiesen; ebenso wird geprüft, dass die Endzeit nach der Startzeit liegt. Ein Test belegt, dass ein Modell-Event mit 08:15–11:30 beim Anwenden auf einen Course auch Events mit 08:15–11:30 erzeugt.

Event-Zeiten werden in Kursansicht, Detail-/Bearbeiten-Modal und Konfliktmeldungen jetzt in Ortszeit (Europe/Berlin) statt UTC ausgegeben. Beim Speichern werden Formularwerte explizit als Ortszeit interpretiert, sodass Bearbeiten Termine nicht mehr verschiebt. Getestet für Sommer- und Winterzeit. Bereits fehlerhaft gespeicherte Events sollten stichprobenartig geprüft werden.

Studiengruppen werden jetzt überall (Auswahllisten, Listen, Detailseiten, Admin) im Schema Zielperiode/Abschluss/SPO/Studiengang/Fachsemester angezeigt, z. B. „SS27/BA/SPO WS2526/BWL/2“, und sind damit eindeutig unterscheidbar. Das Fachsemester wird dafür neu beim UIS-Sync an der Studiengruppe gespeichert; die Zielperiode wird aus Startsemester + (Fachsemester − 1) berechnet. Nachbesserung (PR #469): Liefert die UIS-Planungsprojektion kein auflösbares Startsemester, leitet der Sync es aus der Zielperiode der Zeile ab (Zielperiode − (Fachsemester − 1)); fehlende Startsemester werden als Warnung geloggt. Fehlende Bestandteile werden ausgelassen. Der gespeicherte Name und die daraus abgeleiteten Kurs- und Terminnamen bleiben unverändert. Nach dem Deploy muss einmal der Studiengruppen-Sync laufen.

In der Studiengruppenansicht kann das Fachsemester eines Moduls künftig pro Studiengruppe lokal angepasst werden.
Das ist hilfreich, wenn ein Modul aus den gelieferten Daten keinem Fachsemester zugeordnet ist oder für die konkrete Planung in ein anderes Fachsemester eingeordnet werden soll.
Der lokal gesetzte Wert hat Vorrang und wird für die Einsortierung der Module sowie für die weitere Planung verwendet.
Dabei bleibt der ursprünglich aus UIS gelieferte Wert erhalten und nachvollziehbar; im UIS selbst wird nichts geändert.
In der Detailansicht kann der lokale Wert je Modul gesetzt, geändert oder wieder zurückgesetzt werden.
Wird die lokale Anpassung entfernt, gilt wieder der aus UIS gelieferte Wert.
Die lokale Anpassung bleibt auch nach einer erneuten Aktualisierung der Moduldaten erhalten, sodass die Planung stabil und verlässlich bleibt.

In der Studiengruppenverwaltung wird die Zielperiode künftig direkt aus den gelieferten Studiendaten übernommen und gespeichert.
Dadurch wird sie nicht mehr aus Startsemester und Fachsemester abgeleitet.
Das ist besonders relevant für flexible Studiengruppen mit Fachsemester 0, zum Beispiel im Doktoratsbereich: Hier kann die Zielperiode nun korrekt angezeigt werden, auch wenn kein Startsemester vorhanden ist.
Bei der betroffenen Plan-ID 2026000387 wird nach dem Datenabgleich die Zielperiode 2026 angezeigt.
Für Studiengruppen mit Fachsemester 1 oder höher bleibt das bisherige Verhalten unverändert.
Auch Jahresangaben wie „2026“ werden als Zielperiode korrekt erkannt und in der Anzeige verwendet.
Die gespeicherte Zielperiode erscheint im Anzeige-Label sowie in der Verwaltungsübersicht, sodass Studiengruppen eindeutiger und verlässlicher zugeordnet werden können.

In der Vorplanung können Terminen künftig optional ein oder mehrere Dozenten zugeordnet werden.
Sobald ein Dozent ausgewählt wird, muss zusätzlich der zugehörige Standort angegeben werden, zum Beispiel Wien oder Seekirchen.
Ein Vorplanungstermin bleibt weiterhin auch ohne Dozent gültig, sodass frühe Planungsstände ohne vollständige Lehrzuordnung erfasst werden können.
Zugeordnete Dozenten können beim Anlegen oder Bearbeiten eines Vorplanungstermins ergänzt und wieder entfernt werden.
Die Dozenten und ihre Standorte werden in der Detailansicht sowie in der Kalender- und Listenansicht der Vorplanungstermine angezeigt.
Dadurch ist bereits in der Vorplanung besser erkennbar, welche Lehrpersonen für welche Termine und Standorte vorgesehen sind.
Die Informationen stehen außerdem für nachgelagerte Portale bereit; die konkrete Anzeige und Bestätigung im Dozentenportal wird separat behandelt.

Der Login über Microsoft wurde für den Betrieb unter https://phoenix.isarlabs.de korrigiert.
Künftig verwendet Phönix bei der Microsoft-Anmeldung die sichere HTTPS-Adresse für die Rückkehr zur Anwendung.
Dadurch bricht die Anmeldung nicht mehr mit dem Microsoft-Fehler zur abweichenden Rücksprungadresse ab.
Nach erfolgreicher Anmeldung werden Benutzer wieder wie erwartet zu Phönix zurückgeführt und sind angemeldet.
Auch Links in Einladungs- und Bestätigungsmails werden nun für die Produktionsumgebung mit HTTPS erzeugt.
Damit wird sichergestellt, dass Anmeldung und E-Mail-Links konsistent über die sichere Adresse von Phönix laufen.
Die Dokumentation zur Microsoft-Anbindung wurde um Hinweise für den sicheren Betrieb und zur Fehlerbehebung ergänzt.

In der Dozentenverwaltung gibt es künftig nicht mehr nur „aktiv“ und „inaktiv“, sondern vier Statuswerte: „inaktiv“, „aktiv“, „Pool“ und „gesperrt“.
Bestehende Dozentendaten werden dabei übernommen, sodass bisher aktive Personen weiterhin aktiv und bisher inaktive Personen weiterhin inaktiv bleiben.
Der Status ist in den entsprechenden Verwaltungs- und Detailansichten sichtbar, kann dort geändert und für die Suche bzw. Filterung genutzt werden.
Damit lässt sich zum Beispiel gezielt anzeigen, welche Dozenten sich im Pool befinden und grundsätzlich vorgemerkt sind.
Als aktiv gilt künftig ausschließlich der Status „aktiv“; Personen im Pool oder mit Status „gesperrt“ werden nicht als aktiv behandelt.
Dadurch wird die Planung klarer, weil vorgemerkte, gesperrte und tatsächlich aktive Dozenten sauber voneinander unterschieden werden können.
Beim Abgleich von Dozentendaten bleibt der lokal gepflegte Status erhalten und wird nicht automatisch überschrieben.

In der Studiengruppenverwaltung kann eine Studiengruppe künftig als „Blended Learning 2.0“ gekennzeichnet werden.
Das Kennzeichen wird in der Detailansicht angezeigt und kann dort gesetzt oder bearbeitet werden.
Standardmäßig ist das Kennzeichen bei Studiengruppen nicht aktiv.
Wird es für eine Studiengruppe gesetzt, gilt es durchgängig für alle Zielperioden und Fachsemester dieser Gruppe.
Damit muss die Information nicht mehrfach gepflegt werden, wenn dieselbe Studiengruppe in mehreren Planungszeiträumen erscheint.
Beim Abgleich mit UIS bleibt die lokal gesetzte Kennzeichnung erhalten und wird nicht überschrieben.
Die Kennzeichnung schafft eine verlässliche Grundlage für spätere Planungsschritte, zum Beispiel im Zusammenhang mit standortübergreifenden Kursen oder Verantwortlichkeiten.

In der Studiengruppen-Ansicht wird die bisherige Unterteilung nach Standorten entfernt.
Studiengruppen werden dadurch nicht mehr zusätzlich nach Standorten wie Seekirchen oder Wien aufgeklappt.
Die angezeigte Studierendenzahl einer Studiengruppe umfasst künftig die Summe über alle zugehörigen Standorte.
Damit wird die Übersicht kompakter und besser auf eine standortübergreifende Planung ausgerichtet.
Die Standortinformation geht dabei nicht verloren: In der Detailansicht der Studiengruppe werden die Standorte weiterhin mit der jeweiligen Anzahl Studierender angezeigt.
Getrennte SPO-Varianten bleiben weiterhin separat und werden nicht zusammengeführt.
Die konkrete Aufteilung nach Standorten erfolgt bei Bedarf erst in nachgelagerten Planungsschritten, zum Beispiel auf Kurs- oder Veranstaltungsebene.

Das Feld „didaktisches Modell" (seriell / Blockmodell / Wochenmodell) sorgt bei den Anwendern für Verwirrung, da die Bedeutung der Optionen unklar ist und die Auswahl aktuell keine praktische Auswirkung auf die Planung hat (erst relevant bei einer späteren automatischen Planung). Erläuterung der Modelle: - Wochenmodell: eine ganze Präsenzwoche pro Studiengruppe, jeden Tag ein eigenes Modul (altes HAM-System). - Blockmodell: ein Block je Modul, Prüfungen/Klausuren als eigener Block am Semesterende – Module nicht einzeln inkl. Prüfungsleistung abgeschlossen. - Seriell: Module laufen nacheinander, jedes Modul inkl. Prüfungsleistung abgeschlossen (neues Studienmodell). Die Begriffe stammen aus der HAM-Terminologie und gehen aus der Darstellung der didaktischen Modelle nicht klar hervor. Aufgabe: Entscheiden, ob das Feld entfernt oder aussagekräftig neu definiert wird (klare, verständliche Definition mit tatsächlicher Aussagekraft). Quelle: Phönix-Meeting vom 22.07.2026.

In der Studiengruppen-Übersicht werden gesetzte Filter künftig im Browser gespeichert.
Wenn Sie die Seite /studygroups/ später erneut öffnen, werden die zuletzt verwendeten Filter automatisch wiederhergestellt, sofern keine anderen Filter in der Adresse vorgegeben sind.
Dadurch müssen häufig genutzte Filter nicht bei jedem Seitenaufruf erneut eingestellt werden.
Wenn Sie einen Link mit eigenen Filterangaben öffnen, haben diese Angaben Vorrang vor den gespeicherten Einstellungen.
Beim Zurücksetzen der Filter wird auch der gespeicherte Filterzustand entfernt, damit keine alten Werte unbeabsichtigt wieder erscheinen.
Die bestehende Mandantenauswahl bleibt dabei unverändert wirksam.
Die Änderung betrifft ausschließlich die Studiengruppen-Übersicht und hat keine Auswirkungen auf andere Listenansichten.

In der Vorplanung wurden Termine um zwei zusätzliche Angaben erweitert: einen frei erfassbaren Namen und eine feste Auswahl für die Art der Veranstaltung.
Der Name kann mit bis zu 200 Zeichen gepflegt werden und hilft dabei, Vorplanungstermine eindeutiger zu benennen.
Für die Veranstaltungsart stehen vorgegebene Werte zur Auswahl, z. B. Marketingveranstaltung, Fakultätsmeeting, Defensio, Alumni, Welcome days, Nachholklausur oder Sonderveranstaltung.
Beim Erstellen und Bearbeiten eines Vorplanungstermins können diese beiden Angaben künftig direkt erfasst und geändert werden.
In den bestehenden relevanten Ansichten der Vorplanung werden Name und Veranstaltungsart ebenfalls angezeigt, sofern dort bereits Informationen zu Vorplanungsterminen ausgegeben werden.
Dadurch lassen sich Termine im Alltag leichter unterscheiden, einordnen und wiederfinden.
Bestehende Vorplanungstermine bleiben weiterhin gültig und können wie gewohnt bearbeitet werden.

In der Vorplanung können bestehende Vorplanungstermine künftig geklont werden.
Dabei stehen zwei Varianten zur Verfügung: ein Klon für einen anderen Standort oder ein Klon mit neuem Datum für eine Terminserie.
Beim Standort-Klon wählen Nutzer den gewünschten Ziel-Standort aus; beim Serien-Klon wird ein neues Datum angegeben.
Pro Vorgang entsteht genau ein neuer Vorplanungstermin, während der ursprüngliche Termin unverändert bleibt.
Fachliche Angaben aus dem ursprünglichen Termin werden übernommen, soweit sie für den neuen Termin zulässig sind.
Standortabhängige Angaben, die am Ziel-Standort nicht passen würden, werden nicht ungeprüft übernommen.
Dadurch lassen sich bereits erfasste Vorplanungstermine einfacher wiederverwenden, ohne sie vollständig neu anlegen zu müssen.

In der Vorplanung können Termine künftig mit mehreren Studiengruppen verknüpft werden.
Beim Anlegen und Bearbeiten eines Vorplanungstermins steht dafür eine Mehrfachauswahl der Studiengruppen zur Verfügung; eine Zuordnung zu nur einer Studiengruppe bleibt weiterhin möglich.
Bestehende Vorplanungstermine bleiben erhalten und werden weiterhin mit ihrer bisherigen Studiengruppe angezeigt und bearbeitet.
In der Ansicht einer Studiengruppe erscheinen künftig auch Vorplanungstermine, die zusätzlich mit weiteren Studiengruppen verbunden sind.
Dabei wird darauf geachtet, dass gemeinsame Termine nicht mehrfach als getrennte Einträge angezeigt werden.
Auch bestehende Folgefunktionen, die Vorplanungstermine aus einer Studiengruppe übernehmen oder anzeigen, berücksichtigen diese Mehrfachzuordnung.
So lassen sich gemeinsame Präsenz- oder Planungstermine für mehrere Studiengruppen einfacher pflegen, ohne denselben Termin mehrfach anlegen zu müssen.

In der Hauptnavigation gibt es nun einen eigenen Bereich für „Preplanned Sessions“ sowie eine Kalenderansicht dafür, unabhängig von einzelnen Studiengruppen.
Vorplanungstermine für Präsenzphasen können dort zentral gesucht, gefiltert, angezeigt, neu angelegt und bearbeitet werden.
Die Listenansicht zeigt die Termine übersichtlich mit Seitennavigation und behält die aktuell gewählte Mandantenauswahl auch beim Filtern und Blättern bei.
In der Detailansicht können berechtigte Nutzer die Daten eines Vorplanungstermins prüfen und bearbeiten; beim Anlegen und Bearbeiten stehen nur passende Studiengruppen und Locations des gewählten Mandanten zur Auswahl.
Die Kalenderansicht zeigt die Vorplanungstermine zusätzlich in einer zeitlichen Übersicht und kann ebenfalls nach Studiengruppe oder Location eingeschränkt werden.
Dadurch lassen sich geplante Präsenztermine mandantensicher und zentral verwalten, ohne zuerst in einzelne Studiengruppen wechseln zu müssen.

Bei Vorplanungsterminen kann künftig optional ein Raum angegeben werden.
Die Raumangabe bleibt freiwillig: Termine ohne Raum können weiterhin wie bisher gespeichert, angezeigt und bearbeitet werden.
Wenn ein Raum hinterlegt ist, wird dieser direkt beim Vorplanungstermin angezeigt.
Zusätzlich erscheint der Raum für den Zeitraum des Vorplanungstermins als belegt, sodass die Raumnutzung in den bestehenden Verfügbarkeits- und Buchungsansichten berücksichtigt wird.
Vorplanungstermine ohne Raum erzeugen keine Raumbelegung und verändern damit die bisherige Planung nicht.
So wird frühzeitig sichtbar, wenn ein Raum bereits durch eine Vorplanung vorgesehen ist, ohne dass die flexible Vorplanung eingeschränkt wird.
Bestehende Vorplanungstermine bleiben unverändert gültig und können weiterhin bearbeitet werden.

Im Event-Bereich eines Courses können künftig mehrere Events gleichzeitig ausgewählt und gemeinsam gelöscht werden.
Dafür gibt es pro Event eine Auswahlmöglichkeit; zusätzlich können alle aktuell sichtbaren Events auf einmal ausgewählt werden.
Der Löschvorgang wird erst angeboten, wenn mindestens ein Event ausgewählt wurde, und muss vor dem endgültigen Entfernen bestätigt werden.
Beim gemeinsamen Löschen werden ausschließlich Events des aktuell geöffneten Courses berücksichtigt.
Nicht ausgewählte Events bleiben unverändert bestehen, auch wenn andere Events in derselben Liste entfernt werden.
Nach erfolgreichem Löschen wird die Event-Liste aktualisiert und die Auswahl zurückgesetzt, sodass die entfernten Einträge nicht mehr angezeigt werden.
Die bisherige Möglichkeit, einzelne Events zu löschen, bleibt weiterhin erhalten.

Im Event-Bereich eines Course können bestehende Events künftig für einen weiteren Standort geklont werden.
Dafür steht pro Event eine eigene Aktion „Für weiteren Standort klonen“ zur Verfügung.
Zusätzlich können mehrere Events per Mehrfachauswahl markiert und in einem Schritt für einen ausgewählten Ziel-Standort dupliziert werden.
Für jedes ausgewählte Event wird ein neues Event im selben Course angelegt; das ursprüngliche Event bleibt unverändert bestehen.
Die übernommenen Daten entsprechen den bestehenden Event-Informationen, nur der Standort wird auf den neu gewählten Ziel-Standort gesetzt.
Zur Auswahl stehen nur Standorte, die im jeweiligen Course- und Berechtigungskontext zulässig sind.
Dadurch lassen sich gleichartige Termine für weitere Standorte schneller und einheitlicher anlegen, ohne bestehende Events manuell neu erfassen oder verändern zu müssen.

In der Kursverwaltung können Kurse künftig mehreren Studiengruppen zugeordnet werden.
Dies ist sowohl beim Anlegen eines Kurses aus einer Studiengruppe heraus als auch beim einzelnen Anlegen im Bereich „Courses“ möglich.
Eine einzelne Zuordnung bleibt weiterhin möglich, sodass bestehende Arbeitsweisen unverändert genutzt werden können.
Bereits vorhandene Kurse behalten ihre bisherigen Zuordnungen und können weiterhin angezeigt und bearbeitet werden.
In Ansichten einer Studiengruppe erscheinen nun auch Kurse, die zusätzlich mit weiteren Studiengruppen verknüpft sind, ohne dass doppelte Einträge entstehen.
Wenn aus einem Kurs Events erstellt werden und dabei Studiengruppen übernommen werden, werden künftig alle dem Kurs zugeordneten Studiengruppen berücksichtigt.
Die bestehenden Sichtbarkeits- und Auswahlregeln für Studiengruppen bleiben dabei unverändert.

Für Präsenztermine des Marketings wurde ein Ansatz aufgenommen, diese künftig ebenfalls in Phönix zu planen und sichtbar zu kennzeichnen. Damit könnten Marketingtermine im gleichen System verwaltet werden wie andere hochschulweite Termine. Im Alltag würde dies bedeuten, dass Termine nicht zusätzlich in getrennten Listen oder Systemen vorbereitet werden müssen, sofern die Nutzung für das Marketing freigegeben wird. Die Kennzeichnung soll helfen, Marketingtermine von anderen Veranstaltungen zu unterscheiden. Dadurch kann die Terminübersicht einheitlicher und transparenter werden. Welche Verknüpfungen für das Marketing benötigt werden, zum Beispiel die Anzeige von Terminen auf der Webseite, ist noch zu klären. Die Änderung beschreibt daher zunächst die fachliche Ausrichtung und Vorbereitung einer möglichen Nutzung durch das Marketing.

In der globalen Liste der Vorplanungstermine ist die Klonfunktion nun wieder sichtbar und nutzbar.
Pro Vorplanungstermin stehen die Aktionen „Für Standort klonen“ und „Für Terminserie klonen“ zur Verfügung, sofern sie nach der bestehenden Logik angezeigt werden sollen.
Beim Klonen für einen Standort kann ein Ziel-Standort ausgewählt werden; dabei wird ein neuer Vorplanungstermin für diesen Standort angelegt.
Beim Klonen für eine Terminserie kann ein neues Datum eingegeben werden; auch hier entsteht genau ein neuer Vorplanungstermin.
Der ursprüngliche Termin bleibt in beiden Fällen unverändert.
Damit können bereits erfasste Vorplanungstermine im Alltag einfacher weiterverwendet werden, ohne sie manuell neu anlegen zu müssen.
Zusätzliche Prüfungen stellen sicher, dass die Klonaktionen in der tatsächlich verwendeten globalen Liste künftig nicht erneut unbeabsichtigt fehlen.

In der Termin- und Vorplanung können nun mehrere Räume direkt an einem Event oder Vorplanungstermin ausgewählt werden.
Damit müssen häufig wechselnde Raumkombinationen nicht mehr vorab als eigener virtueller Raum angelegt und gepflegt werden.
Virtuelle Räume bleiben weiterhin verfügbar und können unverändert für wiederkehrende Raumkombinationen genutzt werden.
Auch bestehende Buchungen mit Einzelraum oder virtuellem Raum bleiben gültig und funktionieren wie bisher.
Bei der Prüfung von Raumkonflikten werden künftig alle ausgewählten Räume berücksichtigt – unabhängig davon, ob sie einzeln, als Mehrfachauswahl oder über einen virtuellen Raum eingetragen wurden.
Überschneidungen werden erkannt, sobald mindestens einer der betroffenen Räume bereits im gleichen Zeitraum belegt ist.
In den Termin- und Vorplanungsansichten wird die vollständige Raumliste angezeigt, sodass Planende direkt sehen, welche Räume durch einen Termin belegt sind.

In der Studiengruppenverwaltung können künftig Vorplanungstermine für Präsenzphasen erfasst und gepflegt werden. Diese Vorplanungen bestehen aus Start- und Endzeit, einer Location (Standort) sowie optional einer Notiz – ohne Raum- oder Dozentenangabe. Mehrere Vorplanungstermine dürfen sich zeitlich überschneiden und lassen sich trotzdem speichern, da in diesem Schritt bewusst keine Konflikte geprüft werden. Bei der Auswahl der Location werden nur die für den aktuell gewählten Mandanten verfügbaren Standorte angezeigt.

Im Kurs-/Terminbereich können diese Vorplanungstermine später angezeigt und ausgewählt werden, um daraus Termine zu erstellen. Dabei werden Zeit und Location aus der Vorplanung übernommen, während Raum- und Dozentenangaben leer bleiben. Dadurch lässt sich die Präsenzplanung frühzeitig und standortbezogen vorbereiten, ohne dass bereits alle Details feststehen.

In der Eventverwaltung wurde ein Fehler beim Aktualisieren bestehender Events behoben.
Beim Speichern eines bearbeiteten Events konnte es bisher zu einer Fehlermeldung kommen, wenn Datums- und Zeitangaben verarbeitet wurden.
Künftig werden diese Angaben beim Aktualisieren zuverlässig behandelt.
Dadurch lassen sich bestehende Events wieder ohne Abbruch speichern.
Für Anwenderinnen und Anwender bedeutet das eine stabilere Bearbeitung von Terminen im Alltag.
Bereits angelegte Events können damit sicherer gepflegt und angepasst werden.

In der Studiengruppenverwaltung wird künftig kein Standort mehr an einer Studiengruppe geführt.
Die entsprechenden Angaben wurden aus Listen, Detailansichten, Formularen und möglichen Filtern entfernt.
Beim Anlegen oder Bearbeiten einer Studiengruppe muss daher kein Standort mehr ausgewählt oder gepflegt werden.
Auch bei der Datenübernahme aus UIS werden Standortangaben zu Studiengruppen nicht mehr berücksichtigt.
Die Übernahme funktioniert weiterhin, unabhängig davon, ob UIS diese Angaben noch mitsendet oder nicht.
Dadurch wird die Studiengruppenverwaltung übersichtlicher und entspricht dem überarbeiteten fachlichen Modell, in dem Studiengruppen nicht mehr an einen Standort gebunden sind.

In der Kurs-Detailansicht wird im Bereich Events künftig zusätzlich zum Dozenten auch der Modulverantwortliche des jeweiligen Kurses angezeigt. Diese Information erscheint bei jedem einzelnen Event-Eintrag in der Liste, im gleichen Format wie die Dozentenanzeige. Dadurch ist auf einen Blick erkennbar, wer fachlich für das Modul verantwortlich ist – ohne die Ansicht wechseln zu müssen. Wenn kein Modulverantwortlicher hinterlegt ist, wird dies wie gewohnt als leerer Platzhalter dargestellt. Anlegen, Bearbeiten und Löschen von Events bleiben unverändert; es kommt keine neue Eingabemöglichkeit hinzu. Das erleichtert die Zuordnung und Abstimmung, weil die relevanten Ansprechpartner direkt in der Event-Übersicht sichtbar sind.

In der Kursverwaltung kann einem Kurs künftig nur noch ein didaktisches Modell zugeordnet werden. Wenn bereits ein Modell ausgewählt wurde, wird dieses im Auswahlfeld im Kurs jetzt auch sichtbar angezeigt und nicht mehr als „leer“ dargestellt. Ein erneutes Anwenden desselben Modells erzeugt keine zusätzlichen Termine mehr. Wenn Sie im Kurs auf ein anderes didaktisches Modell wechseln, werden die bisher durch das alte Modell erzeugten Termine entfernt und anschließend die Termine des neu gewählten Modells neu angelegt. Dadurch werden keine unterschiedlichen Modelle mehr innerhalb eines Kurses vermischt. Das hilft, versehentlich zu viele Termine im Kurs zu vermeiden und sorgt für eine konsistente Terminstruktur pro Kurs.

In der Benutzerverwaltung im Admin-Bereich hat der Aktiv/Inaktiv-Schieberegler in Benutzerprofilen künftig wieder eine zuverlässige Wirkung. Bisher ließ sich der Schalter zwar umlegen, der Status wurde nach dem Speichern jedoch nicht übernommen und war nach einem Neuladen unverändert. Künftig wird die Änderung beim Speichern korrekt übernommen und bleibt anschließend auch dauerhaft erhalten. Dadurch können Administratoren Benutzerprofile wieder gezielt aktivieren oder deaktivieren, ohne dass die Einstellung „verloren geht“. Das erleichtert die tägliche Pflege von Benutzerkonten und verhindert unnötige Nacharbeit durch wiederholtes Prüfen und erneutes Speichern.

Beim Anlegen oder Bearbeiten von Terminen werden Überschneidungen künftig auch bei Studiengruppen und Räumen deutlich angezeigt. Wenn eine Studiengruppe oder ein Raum zur gewählten Zeit bereits belegt ist, erscheint nun ein Bestätigungsdialog, der nicht automatisch verschwindet. Sie müssen dann aktiv entscheiden, ob Sie abbrechen oder trotzdem speichern möchten. Bei „Abbrechen“ wird der Speichervorgang beendet und es werden keine Änderungen übernommen – Sie bleiben im Formular. Bei „Trotzdem speichern“ wird der Termin bewusst trotz Doppelbelegung gespeichert, sofern dies fachlich erlaubt ist. Die Warnung für Dozenten bleibt unverändert, da sie bereits zuverlässig angezeigt wird. Dadurch wird verhindert, dass wichtige Hinweise zu Doppelbelegungen bei Räumen und Studiengruppen im Alltag übersehen werden.

In der Kursverwaltung können für Kurse künftig ein Startdatum und ein Enddatum hinterlegt und bei Bedarf angepasst werden. Dabei wird geprüft, dass das Startdatum nicht nach dem Enddatum liegt, damit die Angaben nachvollziehbar bleiben. Die beiden Datumsangaben werden in den relevanten Kursansichten angezeigt, sodass Sie die zeitliche Einordnung eines Kurses direkt sehen können.

Wenn eine Moodle-Kurshülle aus einem Kurs erstellt oder aktualisiert wird, werden diese Datumswerte automatisch übernommen. Änderungen an Start- und Enddatum in Phoenix werden bei der Aktualisierung entsprechend auch an Moodle weitergegeben. Wenn in Phoenix kein Start- oder Enddatum gepflegt ist, werden in Moodle keine Datumswerte überschrieben. Dadurch bleiben Kurslaufzeiten in Phoenix und Moodle konsistent und müssen nicht doppelt gepflegt werden.

In der Bearbeiten‑ und Neuanlegen‑Ansicht für Dozenten im Mandantenkontext (/tenantteachers/{id}/edit/) sind die Formularbereiche jetzt klarer strukturiert. Die Inhalte werden künftig in deutlich getrennten Abschnitten dargestellt, orientiert an der Gliederung der Detailansicht (/tenantteachers/{id}/). Dadurch sind Bereiche wie Stammdaten, Kontakt sowie Bildungs‑ und Berufsinformationen optisch besser voneinander abgegrenzt und schneller zu erfassen. Je nach vorhandener Projektgestaltung kann zusätzlich eine Tab‑Struktur genutzt werden, um zwischen den Abschnitten leichter zu wechseln. An den enthaltenen Feldern ändert sich nichts: Es kommen keine Felder hinzu und es werden keine entfernt. Auch Pflichtfelder, Prüfungen und Fehlermeldungen funktionieren weiterhin wie gewohnt. Speichern, Abbrechen sowie das anschließende Verhalten (z. B. Zurücknavigation) bleiben unverändert.

In der Benutzeroberfläche gibt es jetzt einen eigenen Einstieg zur Verwaltung von „Virtuellen Räumen“ (Zusammenfassung mehrerer physischer Räume). Dort können berechtigte Nutzer virtuelle Räume anzeigen, neu anlegen, bearbeiten und löschen – analog zur bestehenden Raumverwaltung. Beim Anlegen und Bearbeiten wählen Sie einen Namen und die zugehörigen physischen Räume aus; dabei müssen mindestens zwei Räume ausgewählt werden. In den Übersichten und Details ist sichtbar, welche Räume zu einem virtuellen Raum gehören und wie viele enthalten sind. Die Auswahl der Räume ist auf die Räume beschränkt, auf die Sie auch in der normalen Raumverwaltung Zugriff haben. Dadurch bleibt die bestehende Zugriffskontrolle unverändert, und unzulässige Zuordnungen werden beim Speichern zuverlässig verhindert. Zusätzlich wird durch einen Kurztest sichergestellt, dass die Seite für berechtigte Nutzer erreichbar ist.

In der Dozierendenverwaltung gibt es in der Detailansicht jetzt einen neuen Bereich „Sprachkenntnisse“. Dort können Sie pro Dozentin bzw. Dozent mehrere Einträge aus Sprache und Kompetenzniveau erfassen und die Angaben bei Bedarf auch bearbeiten oder löschen. Beim Anlegen und Speichern sind Sprache und Niveau Pflichtangaben, damit die Einträge vollständig sind. Zusätzlich wird verhindert, dass für dieselbe Person dieselbe Sprache mehrfach erfasst wird. Dadurch behalten Sie die Sprachprofile von Lehrkräften übersichtlich und konsistent und können sie bei der Planung und Zuordnung leichter berücksichtigen. Die Sprachkenntnisse werden als zentrale Stammdaten der Lehrkraft geführt und stehen damit auch dann einheitlich zur Verfügung, wenn dieselbe Lehrkraft in mehreren Zusammenhängen genutzt wird.

In der Dozenten-Bewerbung können künftig zusätzlich zu den bekannten Angaben auch Bewerbungsdokumente (z. B. Lebenslauf und weitere Unterlagen) hochgeladen und dauerhaft gespeichert werden. Direkt in der Bewerbung wird dafür eine Dokumentliste angezeigt, in der die hochgeladenen Dateien aufgeführt sind. Zu jedem Dokument ist in dieser Liste auch das Upload-Datum sichtbar, sodass Sie das Alter der Unterlagen erkennen können, ohne die Datei öffnen zu müssen.

Dadurch wird die Prüfung und Nachverfolgung von Bewerbungsunterlagen im Arbeitsalltag einfacher und schneller, weil relevante Informationen auf einen Blick verfügbar sind. Die Sichtbarkeit und der Zugriff auf die Dokumente richten sich weiterhin nach den bestehenden Berechtigungen im Bewerbungs-Kontext. Außerdem wird sichergestellt, dass Dokumente nur im jeweiligen Mandanten sichtbar sind.

Beim Anlegen einer neuen Lehrkraft bleiben Ihre Eingaben künftig erhalten, auch wenn beim Speichern ein Pflichtfeld fehlt oder eine Angabe ungültig ist. Statt dass das Formular danach wieder leer ist, wird es erneut angezeigt – mit allen zuvor korrekt ausgefüllten Feldern. Felder, die noch fehlen oder nicht passen, werden im Formular deutlich als fehlerhaft markiert und mit einer passenden Hinweis-/Fehlermeldung versehen. So sehen Sie sofort, welche Angaben noch ergänzt oder korrigiert werden müssen. Dadurch vermeiden Sie Doppelarbeit, weil Sie nicht alles erneut eingeben müssen. Das Anlegen neuer Dozenten/Lehrkräfte wird damit insgesamt schneller und weniger fehleranfällig.

In der Bearbeitung von Studiengruppen werden die Auswahllisten für Abschluss, Studienprogramm, Studienprüfungsordnung (SPO) und Standort jetzt strikt auf den Mandanten der aktuell geöffneten Studiengruppe begrenzt. Dadurch sehen Sie in diesen Feldern nur noch Einträge, die wirklich zu dieser Studiengruppe gehören, und keine Daten aus anderen Mandanten. Beim Speichern wird außerdem geprüft, dass keine Zuordnung zu einem Eintrag aus einem anderen Mandanten übernommen werden kann. Das verhindert fehlerhafte oder unzulässige Verknüpfungen, auch wenn z. B. ein Link oder eine Eingabe manipuliert wurde. Bereits korrekt gesetzte Werte bleiben beim Öffnen der Bearbeitung weiterhin wie gewohnt vorausgewählt. Insgesamt wird die Datenpflege in Studiengruppen damit konsistenter und sicherer.

In der Studiengruppen-Verwaltung werden beim Datenabgleich künftig auch die Angaben zum Fachsemester aus dem Quellsystem übernommen und in der Studiengruppe gespeichert. Zusätzlich wird beim Synchronisieren jeder einzelnen Studiengruppe automatisch auch der bereits vorhandene Abgleich der zugehörigen Module ausgeführt. Dadurch sind die Modulzuordnungen nach einem Synchronisationslauf konsistenter und müssen seltener separat nachgezogen werden.

In der UserUI werden in der Übersicht und in der Detailansicht einer Studiengruppe jetzt die Felder Startsemester und Fachsemester angezeigt. Damit sind diese Informationen direkt im Alltag sichtbar, ohne dass man sie aus anderen Quellen zusammensuchen muss. In der Studiengruppen-Übersicht steht außerdem ein neuer Filter nach Fachsemester zur Verfügung. So lassen sich Studiengruppen gezielt nach einem bestimmten Fachsemester eingrenzen, und die Liste wird entsprechend serverseitig korrekt gefiltert.

In der Dozentenverwaltung kann in den Stammdaten einer Lehrkraft künftig optional eine WeChat-ID hinterlegt werden. Das Feld „WeChat-ID“ steht in der Detailansicht eines Dozenten unter /tenantteachers/{id}/ zur Verfügung und kann dort eingesehen und bearbeitet werden. Beim Speichern wird der eingetragene Wert übernommen und ist beim erneuten Öffnen der Detailansicht weiterhin sichtbar. Damit lässt sich die Kontaktaufnahme mit Dozierenden im internationalen Umfeld – insbesondere in China – einfacher dokumentieren, wenn dort bevorzugt WeChat genutzt wird. Da es sich um Stammdaten der Lehrkraft handelt, steht die WeChat-ID zentral zur Verfügung, wenn dieselbe Lehrkraft in mehreren Zuordnungen verwendet wird.

In der Modul-Zuordnung eines Dozenten innerhalb eines Tenants kann künftig eine Priorität pro Modul hinterlegt werden. Dafür gibt es ein neues, optionales Zahlenfeld „Priorität“ mit einem erlaubten Wertebereich von 1 bis 100. Eine kleinere Zahl bedeutet eine höhere Priorität, eine größere Zahl eine niedrigere. Beim Eingeben wird darauf geachtet, dass nur Werte innerhalb dieses Bereichs gespeichert werden können. Bereits vorhandene Zuordnungen ohne eingetragene Priorität bleiben weiterhin nutzbar und werden wie gewohnt angezeigt. Dadurch lässt sich im Alltag besser festhalten, welche Module für einen Dozenten wichtiger sind, ohne bestehende Daten nachpflegen zu müssen.

In den didaktischen Modellen können künftig zusätzliche Angaben gepflegt werden: die Laufzeit in Wochen sowie der Modelltyp (Seriell, Blockmodell oder Wochenmodell). Diese Informationen stehen Ihnen auch direkt in der Detailansicht eines didaktischen Modells zur Verfügung. Dadurch lässt sich der Aufbau eines Lehrmodells im Alltag genauer beschreiben und einheitlicher dokumentieren.

Bei den zugehörigen Event-Vorlagen wurden zusätzliche Planungsfelder ergänzt: Reihenfolge (Position), Startwoche und die Woche innerhalb des Moduls (1–6). Außerdem werden die Event-Vorlagen in der Liste jetzt automatisch nach der Position sortiert. Das erleichtert die Übersicht und sorgt dafür, dass Termine in der vorgesehenen Abfolge angezeigt werden.

Beim Hinzufügen eines Moduls zu einer Studiengruppe wird die Auswahl eines bereits vorhandenen Moduls im Formular jetzt ganz oben und damit deutlich sichtbarer angeboten. Wenn Sie ein bestehendes Modul auswählen, werden die übrigen Felder im Formular automatisch mit den Daten dieses Moduls vorbefüllt – auch dann, wenn die Seite nach einer Eingabeprüfung erneut angezeigt wird.

Beim Speichern wird künftig kein neues Modul mehr angelegt, wenn bereits ein vorhandenes Modul ausgewählt wurde. Stattdessen wird die Studiengruppe mit genau diesem Modul verknüpft. Wenn diese Verknüpfung bereits existiert, wird sie nicht doppelt angelegt. Dadurch wird das Risiko deutlich reduziert, versehentlich Dubletten oder Mehrfachzuordnungen zu erzeugen, und die Pflege von Modulen in Studiengruppen wird im Alltag schneller und zuverlässiger.

In der Event-Planung können Sie künftig mehrere physische Räume zu einem zusammengelegten (virtuellen) Raum bündeln und diesen wie einen Raum auswählen, z. B. für Räume mit Trennwand. Solche zusammengelegten Räume lassen sich in der Verwaltung anlegen, bearbeiten und löschen und müssen dabei aus mindestens zwei einzelnen Räumen bestehen. In Events ist klar erkennbar, wenn ein zusammengelegter Raum verwendet wird: Es wird der Name des zusammengelegten Raums angezeigt und zusätzlich die Liste der enthaltenen einzelnen Räume. Pro Event kann entweder ein einzelner Raum oder ein zusammengelegter Raum ausgewählt werden. Wenn ein zusammengelegter Raum gebucht ist, gelten automatisch alle enthaltenen Räume im selben Zeitraum als belegt. Dadurch werden Doppelbuchungen verhindert – auch dann, wenn ein anderer Termin versucht, nur einen der enthaltenen Räume (oder einen anderen zusammengelegten Raum mit Überschneidung) zu belegen.

In der Dozentenverwaltung wurde in den Stammdaten einer Lehrkraft das optionale Feld „Passnummer / ID Card Number“ ergänzt. Dieses Feld ist in der Detailansicht eines Dozenten unter „Bildungs- und Berufsinformationen“ verfügbar und befindet sich direkt unter der „Sozialversicherungsnummer“. Sie können die Passnummer dort künftig einsehen und bearbeiten. Änderungen werden beim Speichern übernommen und sind beim erneuten Öffnen der Detailansicht weiterhin sichtbar. Da es sich um Stammdaten der Lehrkraft handelt, steht die Information zentral zur Verfügung, wenn dieselbe Lehrkraft in mehreren Zuordnungen verwendet wird. Dadurch können Identifikationsdaten vollständiger erfasst werden, ohne zusätzliche Notizen oder Umwege.

In der StudyGroup-Detailansicht gibt es jetzt eine eigene Sektion „Module“ als Einstieg in die Modulverwaltung. Dort werden alle zugeordneten Module gemeinsam angezeigt: sowohl die bereits aus dem angebundenen System stammenden Module als auch manuell hinzugefügte Einträge. Sie können im Kontext einer StudyGroup Module manuell hinzufügen, ansehen, bearbeiten und löschen. Module, die aus dem angebundenen System kommen, bleiben weiterhin sichtbar, können aber nicht bearbeitet oder gelöscht werden. Manuell angelegte Module bleiben zudem erhalten und werden durch bestehende Prozesse aus dem angebundenen System nicht überschrieben oder entfernt. Alle Aktionen sind an den aktuell ausgewählten Mandanten gebunden – damit wird verhindert, dass versehentlich Daten einer anderen Hochschule/Organisationseinheit angezeigt oder geändert werden.

In der Kursverwaltung gibt es in der Detail- und Bearbeitungsansicht künftig ein zusätzliches Feld „Notice“ für längere Hinweise. Dieses Feld ist als mehrzeiliges Textfeld ausgelegt, sodass auch umfangreichere Informationen zum Kurs erfasst werden können. Der Inhalt ist optional und kann leer bleiben, ohne dass bestehende Kurse angepasst werden müssen. Beim Öffnen eines Kurses wird der hinterlegte Text angezeigt. Änderungen am Feld „Notice“ werden beim Speichern übernommen und sind beim erneuten Öffnen des Kurses wieder verfügbar. Dadurch lassen sich kursbezogene Hinweise zentral am Kurs dokumentieren, statt sie separat festzuhalten.

In der Lehrerverwaltung kann künftig pro Standort festgelegt werden, dass ein bestimmter Lehrer für diesen Standort als „Blacklisted“ markiert ist. Diese Markierung gilt nur für die jeweilige Standort-Zuordnung und nicht standortübergreifend. Zusätzlich kann bei Bedarf ein Grund als Notiz hinterlegt werden, der später wieder angezeigt wird. In der Veranstaltungsplanung (Bearbeiten einer Veranstaltung) erscheint bei der Auswahl oder beim Vorschlag eines solchen Lehrers für den betroffenen Standort ein deutlicher Warnhinweis „Blacklisted“ – inklusive Notiz, falls eine hinterlegt wurde. Der Lehrer bleibt trotz Warnung weiterhin auswählbar und wird nicht automatisch aus Vorschlägen entfernt. Dadurch wird sichergestellt, dass Planende frühzeitig auf bekannte Einschränkungen oder Absprachen aufmerksam gemacht werden, ohne den Planungsprozess zu blockieren.

Änderung für Anwender: „Studienbeginn/Kohorte“ bei Studiengruppen

Ab sofort kann bei jeder Studiengruppe der Studienbeginn (Kohorte/Semester) direkt erfasst und genutzt werden.

Was ändert sich in der Anwendung?

• Neues Feld „Studienbeginn“ in der Studiengruppe (aus den bereits vorhandenen Semester-/Periodenwerten).
• Das Feld ist in der UI verfügbar in:
• Anlegen einer Studiengruppe
• Bearbeiten einer Studiengruppe
• Detailansicht einer Studiengruppe (Anzeige im Bereich der akademischen Informationen)
• In der Studiengruppen-Übersicht (/studygroups/) wird der Studienbeginn zusätzlich angezeigt.
• In der Übersicht gibt es einen neuen Filter „Studienbeginn“, mit dem du die Liste gezielt nach Kohorten einschränken kannst. Dieser Filter lässt sich mit bestehenden Filtern kombinieren (z. B. Standort, Abschluss, Programm).

Wichtige Hinweise

• Der Studienbeginn ist optional (kann leer bleiben), damit bestehende Daten weiterhin funktionieren und Werte später nachgetragen werden können.

Nutzen / Mehrwert

• Studiengruppen lassen sich klar nach Kohorten strukturieren, was die Planung und Orientierung verbessert.
• Du findest schneller die richtigen Gruppen, weil du gezielt nach Studienbeginn filtern kannst – auch in Kombination mit anderen Kriterien.

Änderung für Anwender: „Moodle User ID“ bei Dozenten pflegen

In der Dozenten-Zuordnung (TenantTeacher) gibt es künftig ein neues Feld „Moodle User ID“. Damit kann ein Dozent in Phoenix eindeutig einem Benutzer in Moodle zugeordnet werden.

Was ändert sich konkret?

• Neues Feld „Moodle User ID“ in der Dozenten-Detailansicht (wenn leer, wird wie gewohnt ein Platzhalter angezeigt).
• Neues Eingabefeld „Moodle User ID“ im Bearbeiten-Formular, damit der Wert gepflegt und geändert werden kann.
• Beim Speichern werden versehentliche Leerzeichen am Anfang/Ende automatisch entfernt.

Was ist der Nutzen?

• Die Zuordnung zu Moodle kann sauber und eindeutig gepflegt werden – als Grundlage für spätere Auswertungen oder Anbindungen, ohne dass doppelte Zuordnungen im selben Tenant entstehen.

Wichtige Regeln / Verhalten

• Die Moodle User ID muss pro Tenant eindeutig sein (aber nur, wenn sie gesetzt ist).
• Gleiche Moodle User ID im selben Tenant → wird abgewiesen.
• Gleiche Moodle User ID in unterschiedlichen Tenants → ist erlaubt.
• Es gibt keine automatische Verbindung zu Moodle: keine Synchronisation, keine Prüfung gegen Moodle, keine API-Aufrufe.

Hinweis zum bisherigen „TSS-Link“

Das in der Beschreibung erwähnte UI-Feld „TSS-Link“ ist in der Anwendung nicht als eigenes Feld vorhanden (der Link stand/steht ggf. im Bemerkungsfeld). Entsprechend muss in der UI nichts aktiv entfernt werden.

In der Standortzuordnung zwischen den hochschulspezifischen Standort-IDs (UIS) und den globalen Standorten in Phoenix wurden fehlende Zuordnungen ergänzt. Anschließend werden die Standort-Informationen erneut eingelesen, damit Phoenix wieder mit einer vollständigen und korrekten Grundlage arbeitet. Künftig werden Standorte und zugehörige Studiengruppen dadurch wieder richtig angezeigt. Auch fehlende Locations (z. B. bei Standort- oder Detailanzeigen) erscheinen wieder wie erwartet. Das reduziert Verwirrung bei der Auswahl und Zuordnung von Standorten im Alltag. Dadurch wird sichergestellt, dass standortbezogene Informationen in Phoenix konsistent und verlässlich dargestellt werden.

In Phönix stehen künftig auch die Räume des Standorts Seekirchen zur Verfügung. Dafür wurden die vorhandenen Raumdaten aus dem bisherigen System nach Phönix übernommen (relevant für SCU: Seekirchen und Wien). Im Alltag können Sie bei der Planung und Zuordnung von Terminen nun auch Räume in Seekirchen auswählen, statt nur auf die Wiener Räume beschränkt zu sein. Dadurch wird die Raumplanung für Veranstaltungen, insbesondere bei standortübergreifenden Szenarien, vollständiger und konsistenter. Das reduziert Rückfragen und manuelle Workarounds, wenn Termine in Seekirchen stattfinden. Insgesamt ist die Datenbasis für die Raumverwaltung damit aktueller und näher an der realen Nutzung.

Bei der Erstellung und Bearbeitung von Events werden Räume künftig nicht mehr automatisch anhand der benötigten (Prüfungs-)Plätze aus der Auswahlliste ausgeschlossen. Stattdessen sehen Sie in der Raum-Auswahl alle Räume, die grundsätzlich zum gewählten Standort passen und für Sie verfügbar sind. Die Kapazität eines Raums (inklusive Prüfungsplätze bei Prüfungen) wird weiterhin angezeigt, dient aber nur noch zur Orientierung. Wenn Sie einen Raum auswählen, der weniger Plätze hat als benötigt, erhalten Sie dazu einen Hinweis – die Auswahl bleibt jedoch möglich. Auch das Speichern des Events wird dadurch nicht mehr blockiert. Dadurch können Sie Räume flexibler auswählen und besser an die tatsächliche Planungspraxis anpassen.

In Phönix steht künftig eine neue Schnittstelle zur Verfügung, über die externe Systeme Dozenten-Zuordnungen je Hochschule (Tenant-Teacher) abrufen und pflegen können. Dabei sind folgende Aktionen möglich: Datensätze auflisten, einen Datensatz per ID oder E‑Mail finden, neue Einträge anlegen und bestehende aktualisieren. Der Zugriff ist durch eine verpflichtende Anmeldung mit einem Schlüssel und einem Geheimnis abgesichert; ohne gültige Zugangsdaten werden Anfragen zuverlässig abgewiesen. Beim Anlegen wird – falls bereits ein Dozent mit derselben E‑Mail existiert – dieser wiederverwendet und nicht überschrieben, um bestehende Zuordnungen nicht unbeabsichtigt zu verändern. Zusätzlich ist geschützt, dass die E‑Mail eines Dozenten nicht geändert werden kann, wenn dieser Dozent bereits in mehreren Zuordnungen verwendet wird. Dadurch wird die Anbindung an Umsysteme einfacher und gleichzeitig die Datenkonsistenz bei geteilten Dozenten besser gewährleistet. Eine interne Dokumentation mit Beispielen für Aufrufe und typischen Fehlermeldungen wurde ergänzt.

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.

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.

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.