A user may correct changed opening hours immediately, yet other visitors still see the old hours while approval waits. Checking errors before publication also delays accurate updates. In December, we chose to apply permitted edits first and review their history afterward. Delta implemented this through area-specific storage, change history and separate publication requests where needed.

Edit requests and approval queues

Previously, an operator read each request and changed the actual data. This could catch mistakes before publication, but valid corrections had to wait in the same queue. With more venues and contributors, update speed depended less on when someone knew the facts and more on when an operator could read the emails and requests.

We started with areas whose changes could be traced and reversed rather than opening every edit at once. Routine values such as hours could save with history for later review. Publication decisions and basic-information changes requiring judgment remained requests. The aim was to shorten waits for valid corrections while retaining review.

The transition happened in stages. December 2025 introduced immediate hours updates while changes to published basic information still required requests. In March 2026, direct updates expanded to basic information on public documents. The December policy decision therefore did not mean every save route changed simultaneously.

flowchart TD
    accTitle: Apply changes according to their purpose
    accDescr: Allowed routine edits take effect with history while changes requiring publication judgment wait for review.
    U[Authenticated user edit] --> D{Kind of change}
    D -->|Immediate editing allowed| A[Save change and history]
    D -->|Publication judgment needed| Q[Separate review request]
    A --> R[Review afterward]
    Q --> O[Operator decision and application]

Identifying authors and publishing new venues

Reviewing an applied edit first requires knowing its author. The server obtains the author from the authenticated account and stores it in history. Accepting an arbitrary browser-supplied name would not identify who made the change. Identifying an account, however, does not give it every publication decision.

A new venue begins as a private draft absent from search. Saving that draft initially followed a different process from publication. After checking the author and the current public or closed state, the server recorded publication requests in arcade_ticket_request for review.

In late March, publication changed to direct application after server-side requirements checks. The requester must be the author, and the venue must not already be public or closed. Required material—games and contact details, or hours and photos—is also checked. Reducing individual operator approval did not remove checks that a new venue contains the necessary information.

Area versions and current references

Retaining earlier values makes reversal possible. Hours are saved as a new arcade_hour record rather than overwritten, and the document’s hour references the current record. Basic information, communication channels, facilities and games likewise have area records and current references, allowing one area to change independently.

The shared reference-update operation reads the earlier value, applies the next one and writes arcade_changelog: changed for the area, from and to for the states, and by for the author. Updating the current reference and storing history in one database transaction avoids publishing a new state without its corresponding history.

The new hours record is created before that shared transaction. If the current-reference update fails, cleanup attempts to delete the new record. Version creation and every subsequent step are therefore not one transaction; the atomic guarantee covers the current reference users read and its change history.

sequenceDiagram
    accTitle: Commit the current reference and history together
    accDescr: After creating an hours record the server updates the current reference and actor-linked history in the same database transaction.
    participant U as Editor
    participant S as Server
    participant D as Database
    U->>S: Authentication and hours edit
    S->>D: Create a new hours record
    S->>D: Update reference and save from to by
    D-->>S: Commit or cancel together
    S-->>U: Save result

Evidence for reviewing applied changes

Review starts by locating who changed which area of which arcade, then comparing from and to. For example, correcting one price needs different examination from clearing all opening hours. A timeline alone cannot provide the actual values needed for that assessment.

History does not establish that the resulting information matches conditions on site. It supplies earlier states and evidence to inspect. A review request similarly alerts an operator to something requiring attention; accepting the request does not itself complete an edit or an account sanction. The content and appropriate response still require examination.

Restoring earlier states and account action

When an edit is wrong, restoration selects an earlier state for the affected area and resets its current reference. The target must belong to the same arcade and area. Linking another document’s record would damage the data relationship rather than restore it.

Restoration leaves the original change intact and adds its own history entry, allowing reviewers to see both the edit and its reversal. Restoring a document does not automatically restrict the author’s account. Correcting content and deciding account action each require consideration.

flowchart TD
    accTitle: Boundaries of restoration and operating decisions
    accDescr: Compare actual changes and restore an earlier state belonging to the same venue and part. Restoration creates history while account actions require a separate decision.
    S[Current state and history] --> A[Compare before and after]
    A -->|Problem confirmed| C[Select earlier state of same venue and part]
    C --> R[Restore reference and add history]
    A -->|Operating judgment needed| O[Separate review and action]

Update speed and ongoing review

Permitted edits no longer wait until an operator opens the request. Incorrect information can therefore remain visible until review. History, review requests and restoration need an operating practice that actually examines records and responds. Faster updates remain sustainable only with that continuing work.

Related record: Musecat engineering notes.

Related updates

• Parking lot information Upated