HADOS Data Models: HabboUser and Dado Full Reference

HADOS persists all tournament data in two Firestore collections, each backed by a strict TypeScript interface. HabboUser represents every participant or staff member in the system, while Dado represents a tournament environment (dice group). Understanding these shapes is the starting point for any integration, admin scripting, or security-rule authoring.

HabboUser

Every authenticated player, intermediary, Dado Admin, and Global Admin is stored as a HabboUser document inside the users collection. The document ID equals the Firebase Authentication UID for self-registered accounts, and is an auto-generated Firestore ID for players added manually by staff.

interface HabboUser {
  id: string;           // Firestore document ID (Firebase Auth UID for self-registered,
                        // auto-generated for manually added players)
  username: string;     // Habbo nickname — used as the key for avatar URL generation
  email: string;        // Real email for registered users;
                        // dummy pattern for manually added: {username}@dummy-habbo.com
  points: number;       // Tournament score, stored to 1 decimal (e.g. 37.5)
  previousRank: number; // Rank before the last points update — used to show rank trends
  currentRank: number;  // Current rank after the last sort + batch write
  avatarUrl: string;    // https://www.habbo.es/habbo-imaging/avatarimage
                        //   ?user={username}&direction=3&head_direction=3
                        //   &gesture=std&size=m
  createdAt: string;    // ISO 8601 timestamp, e.g. "2025-06-20T18:00:00.000Z"
  role: 'global_admin' | 'dado_admin' | 'intermediario' | 'jugador';
  dadoId?: string;      // ID of the Dado this user belongs to.
                        // Omitted for global_admin accounts.
}

Field reference

string

required

Firestore document ID. Equals user.uid from Firebase Auth for self-registered accounts. For players added manually via the Crear Usuario modal, this is an auto-generated Firestore document reference ID.

username

string

required

The player’s Habbo Hotel nickname exactly as it appears in the game. This value is used verbatim to construct the avatar image URL and to query participations across multiple Dados.

string

required

For self-registered users this is the real email address they signed up with. For players added manually by staff, the application writes a synthetic placeholder: {username}@dummy-habbo.com (all lowercase). These dummy addresses allow the app to store a consistent email field without requiring the player to create a Firebase Auth account.

points

number

required

Tournament score accumulated by the player within their Dado. Stored with up to one decimal place of precision (e.g. 42.5). The app uses parseFloat(...toFixed(1)) on every write to enforce this precision. Points can be negative during subtraction but are floored at 0 in all UI actions.

previousRank

number

required

The player’s rank as it was before the most recent points update. Used by the leaderboard to render the rank-change arrow (↑ / ↓ / –).

currentRank

number

required

The player’s rank after the most recent sort-and-batch-write cycle. Ranks start at 1 and increment without gaps.

avatarUrl

string

required

Pre-computed Habbo avatar image URL. The pattern is:

https://www.habbo.es/habbo-imaging/avatarimage
  ?user={encodeURIComponent(username)}
  &direction=3
  &head_direction=3
  &gesture=std
  &size=m

The leaderboard also appends &headonly=1 inline when rendering small circular avatars, but the stored avatarUrl field does not include that parameter.

createdAt

string

required

ISO 8601 timestamp string generated with new Date().toISOString() at the moment the document is first written.

role

'global_admin' | 'dado_admin' | 'intermediario' | 'jugador'

required

The user’s stored role. Note that the effective role displayed in the UI is computed by getActiveRole() (see Permissions), which may differ from this stored value depending on which Dado is currently active.

dadoId

string

The Firestore document ID of the Dado this user belongs to. This field is omitted for global_admin accounts, which have access to all Dados.

global_admin users do not have a dadoId field. All queries that filter by dadoId will therefore exclude them, which is intentional — Global Admins see all Dados via a separate full-collection listener.

Dummy email pattern

When a staff member adds a player manually through the Crear Usuario modal, HADOS cannot create a Firebase Auth account on their behalf (only the player themselves can do that). To maintain a consistent email field across all documents, the app synthesises a placeholder address:

{username_lowercased}@dummy-habbo.com

// Examples:
kingjamesfire@dummy-habbo.com
xslash-@dummy-habbo.com

These addresses are never used for authentication. If the player later self-registers with their real email, their Auth UID will not match the manually-created document — a Dado Admin or Global Admin must reconcile the two records.

Example Firestore document

{
  "id": "abc123uid",
  "username": "xSlash-",
  "email": "xslash-@dummy-habbo.com",
  "points": 147.5,
  "previousRank": 3,
  "currentRank": 2,
  "avatarUrl": "https://www.habbo.es/habbo-imaging/avatarimage?user=xSlash-&direction=3&head_direction=3&gesture=std&size=m",
  "createdAt": "2025-06-20T18:30:00.000Z",
  "role": "jugador",
  "dadoId": "dado_vip_001"
}

Dado

A Dado is a self-contained tournament environment — think of it as a dice room or competitive group. Each Dado has its own leaderboard, rules, schedule, prize configuration, and assigned admin. The dados collection stores one document per Dado; the document ID is always Firestore auto-generated.

interface Dado {
  id: string;               // Firestore auto-generated document ID
  name: string;             // Display name shown in the navbar and leaderboard header
  code?: string;            // Optional join/invite code (reserved for future use)
  adminId?: string;         // Firebase Auth UID of the assigned Dado Admin
  adminEmail?: string;      // Email address of the Dado Admin
  adminName?: string;       // Habbo username of the Dado Admin
  createdAt: string;        // ISO 8601 timestamp
  startDate?: string;       // Tournament start date — YYYY-MM-DD format
  endDate?: string;         // Tournament end date   — YYYY-MM-DD format
  rules?: string[];         // Array of rule strings, one element per line entered in UI
  schedule?: string[];      // Array of schedule strings, one element per line
  totalPrize?: string;      // Free-text prize description, e.g. "3000 USDT"
  qualifyingCount?: number; // Number of top players who qualify for finals (default 12)
}

Field reference

string

required

Auto-generated Firestore document ID, created when the Global Admin submits the Generar Dado form.

name

string

required

Human-readable name of the Dado, e.g. "Dado VIP" or "Dado Alpha". Displayed in the navbar badge and throughout the admin panels.

code

string

Optional invite or join code. Reserved for future feature development; not currently used by any UI logic.

adminId

string

The Firebase Auth UID of the user who has been assigned as Dado Admin. Set via a batch write that simultaneously updates the Dado document and the target HabboUser document. Used by getActiveRole() to determine whether the current user is the Dado Admin without relying solely on their stored role field.

adminEmail

string

Denormalized email of the Dado Admin, written alongside adminId for display purposes in the staff panel.

adminName

string

Denormalized Habbo username of the Dado Admin. Displayed in the Intermediarios tab with their avatar.

createdAt

string

required

ISO 8601 timestamp generated at the moment the Global Admin creates the Dado.

startDate

string

Tournament start date in YYYY-MM-DD format (e.g. "2025-06-20"). Set (or reset) when the Dado Admin triggers Crear Nuevo Torneo. The UI renders this as DD/MM using the formatTournamentDate() helper.

endDate

string

Tournament end date in YYYY-MM-DD format. Displayed alongside startDate in the Info tab.

rules

string[]

Array of rule strings. Each element corresponds to one line entered in the Reglas textarea in the Dado Admin panel. Stored and retrieved preserving the original order.

schedule

string[]

Array of schedule/calendar strings, following the same one-element-per-line convention as rules.

totalPrize

string

Free-text description of the prize pool, e.g. "3000 USDT" or "1000 Credits + VIP Badge". Defaults to "3000 USDT" in the admin form if not yet set.

qualifyingCount

number

How many top-ranked players from this Dado qualify for the grand final. Defaults to 12 if not configured.

Example Firestore document

{
  "id": "dado_vip_001",
  "name": "Dado VIP",
  "adminId": "uid_admin_xyz",
  "adminEmail": "admin@habbo.com",
  "adminName": "KingJamesFire",
  "createdAt": "2025-06-15T12:00:00.000Z",
  "startDate": "2025-06-20",
  "endDate": "2025-08-02",
  "rules": [
    "1. Los puntos se acumulan al ganar partidas verificadas en tu Dado asignado.",
    "2. Los intermediarios de tu Dado son los únicos autorizados para verificar y cargar puntos.",
    "3. Los premios se distribuirán directamente según la configuración de tu administrador."
  ],
  "schedule": [
    "• Rondas Clasificatorias: Lunes a Viernes 18:00 - 22:00 UTC",
    "• Gran Final: Domingo 2 de Agosto a las 20:00 UTC"
  ],
  "totalPrize": "3000 USDT",
  "qualifyingCount": 12
}

Relationship: HabboUser ↔ Dado

The two models are linked by a single foreign-key field:

HabboUser.dadoId  →  Dado.id

A HabboUser document with dadoId: "dado_vip_001" belongs to the Dado whose document ID is "dado_vip_001". This relationship is one-to-one at the Firestore-document level: each player document belongs to exactly one Dado. However, the same Habbo username can appear in multiple Dado documents (because Dado Admins can manually add the same player to their own Dado), so participation queries use where('username', '==', ...) to find all records for a given real user.

users/
  ├─ {uid_A}   → { username: "xSlash-", dadoId: "dado_vip_001", ... }
  ├─ {uid_B}   → { username: "xSlash-", dadoId: "dado_alpha_002", ... }
  └─ {uid_C}   → { username: "KingJamesFire", role: "dado_admin", dadoId: "dado_vip_001", ... }

dados/
  ├─ dado_vip_001   → { name: "Dado VIP", adminId: "uid_C", ... }
  └─ dado_alpha_002 → { name: "Dado Alpha", adminId: null, ... }

global_admin users have no dadoId field. They are not participants in any specific Dado and instead gain access to all Dados via a full-collection onSnapshot listener on dados.

Setup

Reference

HabboUser

Field reference

Dummy email pattern

Example Firestore document

Dado

Field reference

Example Firestore document

Relationship: HabboUser ↔ Dado

Build docs developers (and LLMs) love

Setup

Reference

Documentation Index

​HabboUser

​Field reference

​Dummy email pattern

​Example Firestore document

​Dado

​Field reference

​Example Firestore document

​Relationship: HabboUser ↔ Dado

Build docs developers (and LLMs) love

HabboUser

Field reference

Dummy email pattern

Example Firestore document

Dado

Field reference

Example Firestore document

Relationship: HabboUser ↔ Dado