6. Runtime view

Scenario 1: bootstrap a normal request

sequenceDiagram
  participant B as Browser
  participant P as Page controller
  participant D as defaultincludes.inc
  participant S as Session
  participant L as Language
  participant DB as Database
  participant U as Upgrade logic

  B->>P: HTTP request
  P->>D: require
  D->>D: load autoloader and defaults
  D->>D: load config.inc.php and site config
  D->>S: initialize selected session
  D->>L: initialize locale and catalogues
  D->>DB: initialize database adapter
  D->>U: check schema version
  D-->>P: standard request context
  P-->>B: rendered response

The order matters. Session initialization happens before error infrastructure to reduce interface-version conflicts with third-party systems such as Joomla.

Scenario 2: create a booking

sequenceDiagram
  participant U as User
  participant F as edit_entry.php
  participant H as edit_entry_handler.php
  participant A as Authorization/policy
  participant Q as Booking persistence
  participant DB as Database
  participant M as MailQueue

  U->>F: Open booking form
  F->>A: Check access and available slot
  F-->>U: Form and policy constraints
  U->>H: Submit booking
  H->>A: Validate identity, input, policy, conflicts
  H->>Q: Create entry or recurrence
  Q->>DB: Transactional writes
  DB-->>Q: Stored booking
  H->>M: Queue notifications
  H-->>U: Redirect to calendar or entry
  M->>M: Flush during shutdown

Database checks remain authoritative; client-side availability is only a user experience aid.

Scenario 3: authenticate

sequenceDiagram
  participant P as Protected page
  participant S as Session adapter
  participant A as Auth adapter
  participant I as Identity source

  P->>S: getCurrentUser()
  alt no current identity
    P->>S: request authentication
    S->>A: validate credentials or initiate SSO
    A->>I: backend-specific verification
    I-->>A: identity and attributes
    A-->>S: MRBS user
    S-->>P: authenticated identity
  else existing session
    S-->>P: current identity
  end
  P->>P: compare access level and resource rules

Scenario 4: schema upgrade

During bootstrap, upgrade logic compares the stored schema version with the application's expected version. If migration is necessary, an administrator may supply a database account able to alter the schema. Upgrade steps modify tables and record the new version before ordinary operation continues.