Entwicklerhandbuch

Tabellen-Detail

Datenmodell

Tabellen-Detail

Tabellenprofile mit Zweck, Tenant-Key, Kritikalität, Beziehungen und technischer Spaltenstruktur.

DB-Tabellen: 333Views: 0Trigger: 0
Tabellen-Detail

hcc_hotel_user

Vertiefte Sicht auf fachlichen Zweck, Mandantenbezug, Nutzungsstatus, Datenverantwortung, Risiken und Spaltenstruktur dieser Tabelle.

← Zurück zu Datenbank

Core / HotelNutzung: aktivKritikalität: hochTenant-Key: hu_hotel_idGo-Live: hoch
36
Spalten
15
Dateibezüge
15
Lese-/Schreibhinweise
2
ID-/Verknüpfungsfelder
Kritischer Bereich
Diese Datei oder Tabelle ist fachlich bzw. technisch besonders sensibel. Änderungen sollten immer mit Blick auf Abhängigkeiten, Scope und Seiteneffekte geprüft werden.
Go-Live-relevant
Dieser Bereich ist für sichtbare, operative oder produktive Abläufe besonders relevant.
Tenant-/Hotelbezug
Dieser Bereich arbeitet direkt mit hotel- bzw. mandantenbezogenem Scope. Änderungen sollten immer auf saubere Zuordnung und Scope-Logik geprüft werden.

Langbeschreibung

Hotel-Benutzer und Zugriffszuordnung

Diese Tabelle verbindet Benutzerkonten mit einem Hotel und legt fest, welche Personen im jeweiligen Hotel-System arbeiten dürfen. Sie ist damit die Grundlage dafür, dass nicht jeder alles sehen oder bearbeiten kann.

Überblick
Kurzbeschreibung

Diese Tabelle verbindet Benutzerkonten mit einem Hotel und legt fest, welche Personen im jeweiligen Hotel-System arbeiten dürfen. Sie ist damit die Grundlage dafür, dass nicht jeder alles sehen oder bearbeiten kann.

Fachlicher Zweck
Wofür diese Tabelle gebraucht wird

Die Tabelle speichert, welche Benutzer zu welchem Hotel gehören und in welchem organisatorischen Zusammenhang sie dort arbeiten. Sie bildet damit die praktische Zuordnung zwischen Benutzerverwaltung und Hotel-Mandant ab.

Warum es sie gibt

Ein Hotel arbeitet in der Regel nicht nur mit einem einzigen Login. Es gibt Eigentümer, Manager, Rezeption, Marketing, Service oder externe Partner. Damit das System weiß, welche Person zu welchem Hotel gehört und welche Daten sie überhaupt sehen darf, braucht es eine zentrale Zuordnungstabelle.

Nutzen im Alltag

Die Tabelle macht Mehrbenutzerfähigkeit überhaupt erst praxistauglich. Sie sorgt dafür, dass Hotels mit mehreren Mitarbeitern sicher arbeiten können, ohne dass Daten anderer Hotels sichtbar werden oder jeder Benutzer pauschal Vollzugriff erhält.

Einfach erklärt
Für Nicht-Techniker

Einfach erklärt ist dies die Mitgliederliste eines Hotels im System. Hier wird festgelegt, welche Personen zu einem Hotel gehören und dort im Backend arbeiten dürfen. Ohne diese Zuordnung könnte das System nicht sauber unterscheiden, welcher Benutzer für welches Hotel zuständig ist.

Technische Einordnung
Für Entwickler

Technisch ist dies eine mandantenbezogene Zuordnungs- bzw. Membership-Tabelle zwischen Benutzerobjekten und Hotelobjekten. Sie wird typischerweise für Scope-Prüfungen, Rollenlogik, Sichtbarkeitsentscheidungen, Backend-Zugriffe und organisatorische Rechteprüfungen verwendet. Je nach Implementierung kann sie zusätzlich Status-, Rollen- oder Aktivitätsinformationen pro Benutzer-Hotel-Beziehung enthalten.

Was Änderungen auslösen können

Änderungen an dieser Tabelle wirken sich oft direkt auf Login-Flows, Backend-Sichtbarkeit, Rechteprüfungen und Mandantenabgrenzung aus. Anpassungen sollten deshalb immer gemeinsam mit Authentifizierung und Rollenmodell betrachtet werden.

Typische Nutzung und Inhalte
Typische Nutzung
  • Zuordnung eines Benutzers zu einem bestimmten Hotel
  • Prüfung, ob ein Benutzer in diesem Hotel arbeiten darf
  • Grundlage für Rollen- und Rechteentscheidungen im Backend
  • Filtern von hotelbezogenen Daten nach dem angemeldeten Benutzerkontext
Hauptinhalte
  • Benutzerbezug
  • Hotelbezug
  • Mitgliedschafts- oder Aktivstatus
  • organisatorische Zuordnung innerhalb des Hotels
  • optionale Rollen- oder Rechteinformationen pro Hotelzuordnung
Beispiele
  • Ein Hotelmanager erhält Zugriff auf das Hotel-Dashboard seines Hauses
  • Eine Mitarbeiterin der Rezeption darf nur die Daten ihres Hotels sehen und bearbeiten
  • Ein Benutzer wird aus einem Hotel entfernt und verliert dadurch den Zugriff auf dessen Inhalte
Beziehungen und Risiken
Wichtige Beziehungen
  • Verknüpft Benutzerobjekte mit der zentralen Hotel-Tabelle
  • Wird häufig gemeinsam mit Session-, Login- und Rollenlogik ausgewertet
  • Ist relevant für Backend-Bereiche, die nur hotelbezogen sichtbar sein dürfen
Risiken
  • Fehlerhafte Zuordnungen können dazu führen, dass Benutzer auf das falsche Hotel zugreifen
  • Unscharfe Rollen- oder Statuslogik kann zu Sicherheits- und Berechtigungsproblemen führen
  • Bei fehlender Deaktivierung ehemaliger Benutzer bleiben ungewollte Zugriffe möglich
Hinweise
  • Diese Tabelle ist für Multi-Tenant-Sicherheit besonders wichtig
  • Sie sollte immer zusammen mit Benutzer-, Rollen- und Hotelkontext verstanden werden

Steckbrief

Wofür diese Tabelle da ist

Dieser Bereich erklärt in kompakter Form, welche Aufgabe die Tabelle im Projekt hat und wie wichtig sie für Betrieb und Weiterentwicklung ist.

Projektkontext und Verantwortung
Modul / BereichCore / Hotel
Status im Projektaktiv
Hotel- / Mandanten-Schlüsselhu_hotel_id
Wichtigkeithoch
Relevanz im Betriebhoch
Datenbank-EngineInnoDB
Zweck und Aufgabe

Speichert hotelbezogene Benutzerkonten für Verwaltung, Anmeldung, Aktivierung und Passwort-/E-Mail-Workflows.

Wichtige Beziehungen

Wird im Code von 15 Datei(en) direkt referenziert. | Soft-Delete- oder Statuslogik ist in der Struktur erkennbar. | Verknüpft Hotels mit internen Verwaltungsbenutzern. | Relevant für Login, Aktivierung, Passwort-Reset und Zugriffsstatus.

Risiken bei Änderungen

Fehlerhafte Benutzer-, Aktivierungs- oder Passwortdaten wirken direkt auf Zugang, Sicherheit und Betriebsfähigkeit.

Praktischer Hinweis

Kritische Verwaltungsbenutzer-Tabelle mit Authentifizierungsbezug.

Datenverantwortung

Datenart und Verantwortung

Hier siehst du, welche Art von Daten in der Tabelle liegt und worauf man bei Pflege, Historie und Umbauten achten sollte.

Art der gespeicherten Daten
DomäneCore
Datenklassecore
Lifecycledauerhaft
PIIja
Aufbewahrung und Historie

Benutzer-, Login- und Sicherheitsdaten nur mit Datenschutz- und Sicherheitsbezug ändern oder bereinigen.

Worauf bei Datenqualität zu achten ist

Hotelbezug, Aktivierungsstatus, Codes und Passwort-/Mail-Workflows konsistent halten.

Risiko bei Umbauten

Änderungen mit Login, Session-, Aktivierungs- und Passwortlogik abstimmen.

Führende Datenquelle

Hotelbezogene Benutzerkonten im Verwaltungs-/Backoffice-Kontext.

Nutzung

Wo die Tabelle verwendet wird

Dieser Bereich zeigt, in welchen Dateien oder Abläufen die Tabelle vorkommt. Das hilft beim Verstehen von Auswirkungen vor Änderungen.

Wird gelesen von15 Lese-Hinweise
hotel/arrangement.phphotel/ausstattungen.phphotel/aus_freizeit.phphotel/aus_gastronomie.phphotel/aus_hotelausstattung.phphotel/aus_hotelthemen.phphotel/aus_zahlungsmittel.phphotel/benutzerverwaltung.phphotel/edit_arrangement2.phphotel/index.phphotel/konto.phphotel/pass.phphotel/settings.phphotel/stammdaten.phphotel/staygreenseal_hotels_landing.php
Wird beschrieben von0 Schreib-Hinweise

Aktuell sind keine schreibenden Prozesse oder Hinweise dokumentiert.

Zusätzliche Hinweise8 Einträge
#hcc#hotel#user#used#status#users#auth#admin

Schlüssel & Lifecycle

Wichtige Strukturmerkmale

Hier werden technische Merkmale der Tabelle zusammengefasst, zum Beispiel Schlüssel, Statusfelder und typische Verknüpfungsspalten.

Primärschlüssel
hu_id
Eindeutige Felder und Indizes
hu_id
Status-, Lösch- und Sichtbarkeitsfelder
hu_aktiv
Zeitstempel, Audit und Verknüpfungen
hu_createdhu_updatedhu_hotel_idhu_ipnummer

Weiterarbeiten

Was noch dazugehört

Wenn du die Tabelle weiter untersuchen willst, findest du hier passende Dateien und fachlich verwandte Tabellen.

Spaltenstruktur

Spalten im Überblick

Hier siehst du die Felder der Tabelle mit Typ, Standardwerten und technischen Zusatzinformationen.

Spaltenstruktur öffnen36 Spalten
SpalteTypNullDefaultKeyExtraKommentar
hu_idint(11)NOPRI
hu_hotel_idint(11)YESNULL
hu_freeint(1)YESNULL
hu_14tage_testint(1)YESNULL
hu_14tage_datumdatetimeYESNULL
hu_verwaltungint(1)YESNULL
hu_namevarchar(100)YESNULL
hu_anredevarchar(10)YESNULL
hu_vornamevarchar(150)YESNULL
hu_nachnamevarchar(150)YESNULL
hu_emailvarchar(150)YESNULL
hu_passwortvarchar(250)YESNULL
hu_passwort_updatevarchar(255)YESNULL
hu_createdtimestampYEScurrent_timestamp()on update current_timestamp()
hu_updatedtimestampYEScurrent_timestamp()
hu_email_updatevarchar(100)YESNULL
hu_email_timetimestampYESNULL
hu_emailcodevarchar(15)YESNULL
hu_passwort_timetimestampYESNULL
hu_passwortcodevarchar(255)YESNULL
hu_aktivint(1)YESNULL
hu_onlineint(1)YESNULL
hu_email_codevarchar(150)YESNULL
hu_free_codevarchar(20)YESNULL
hu_free_code_benutztint(1)YESNULL
hu_free_code_timetimestampYESNULL
hu_free_kontrollzahlvarchar(255)YESNULL
hu_ipnummervarchar(250)YESNULL
hu_hostnamevarchar(250)YESNULL
hu_kontrollzahlvarchar(250)YESNULL
hu_bestaetigtint(1)YESNULL
hu_bestaetigung_datumdatetimeYESNULL
hu_ipnummer2varchar(200)YESNULL
hu_hostname2varchar(200)YESNULL
hu_online_seitdatetimeYESNULL
hu_last_logindatetimeYESNULL