Updating values directly in an editor makes arcade changes easier to apply. Without a way to find earlier content after a mistake, however, administrators still need to watch edits closely. Opening editing to users requires tools for examining and recovering changes as well as entering them.

Gamma introduces OAuth login, role-based permissions and request storage in userTicket. Associating the account with submitted content prepares the service for broader participation.

Direct updates and change history

PocketBase SDK updates reduced manual work, but there was no recovery feature. If someone entered incorrect hours, for example, the current value alone would not reveal the previous submission. Adding more editors under those conditions would add more checking.

We decided to preserve both who submitted a change and what values they sent. Earlier requests provide material to inspect and reapply after a problem is discovered.

flowchart TD
    accTitle: Accounts and the editing entry point
    accDescr: Identify the account, distinguish roles, then edit through dedicated APIs.
    A["OAuth login"] --> B
    B["Role check"] --> C
    C["Part-specific edit API"]

OAuth login and editing roles

OAuth uses an external login provider to establish account identity. Document editing now requires that login, with super-administrator, administrator and member roles. Recognizing an account does not itself grant administrator operations.

Writes also move through APIs for individual document areas. An API is the route for requesting a server-side change. We blocked general PUT overwrites so identity checks and request storage accompany the dedicated editing path.

flowchart TD
    accTitle: Recovery that retains requests
    accDescr: Submit a stored earlier request as a new request through the same path.
    A["Retain request JSON"] --> B
    B["Select a past request"] --> C
    C["Register again as a new request"] --> D
    D["Apply through the same edit flow"]

Stored requests and reapplication

JSON received by the editing API is stored in userTicket. JSON represents the submitted fields and values. Preserving that input makes it available for comparison with the current document and for recovery requests.

Recovery selects values from an earlier ticket and registers a new request through the same editing process. The old ticket remains and the restoration is another submission. This reapplies a document's input rather than restoring the entire server from a backup.

flowchart TD
    accTitle: Protection that remains
    accDescr: Apply cooldowns and approval for sensitive edits alongside retained history.
    A["Edit request"] --> B
    B["Creation cooldown and history"] --> C
    C["Administrator approval for sensitive changes"] --> D
    D["Public application"]

Repeated submissions and sensitive changes

Ticket creation has a cooldown, a waiting period before another submission. It limits rapid repetition and spam. Photo uploads, new arcades and closure changes still require administrator approval before publication.

Authors and submitted values can now be located and earlier requests reapplied. The stored material remains raw JSON, so validation and consistent formatting need further work. We plan to operate ordinary corrections alongside separate checks for changes that require review before publication.

Reference: Musecat engineering notes.