Your account

HOL-D081Story implementation: Planned

Review and change approved platform settings

operations · Proposed launch phase 1

Start from Home

Review as Platform administrator · Full workflow planned

User story

As a platform administrator, I want to preview and apply only settings within my assigned authority so platform changes are controlled and recoverable.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • List only explicitly approved editable settings with their current value, purpose and allowed scope. The initial settings list must be agreed before building writes.
  • Validate a proposed change, preview its effect and require an explicit confirmation appropriate to its impact.
  • Show success, failed validation, conflict and revert-to-prior-value outcomes with a dated change history.
  • Keep credentials, security/permission policy, live billing and deployment controls outside ordinary settings. These require separate approval and workflows.
  • Platform administrator is a proposed review perspective; this story does not grant unrestricted configuration access or enable a live backend.

What to check in the demo

Follow these steps from the role’s landing page through navigation and feature checks.

Review as

Platform administrator

Start here: Home

Choose the Robin Park dummy account and open its assigned Platform administrator Home without a password or authenticator prompt. This dev-only Home review does not verify MFA or unlock protected staff actions. Use your own provisioned staff account and authenticator when reviewing those actions.

Navigation from sign-in

  1. 01Open the fictional Platform administrator account through the connected sign-in service. Seeded Home review opens directly. Real HOL staff access and protected actions require an authenticator check.
  2. 02Start on Platform administrator Home and open Features + permissions. Platform settings has no dedicated control panel yet.

Feature checks start here

Review and change approved platform settings · Full workflow planned

Planned full workflow. Existing workspace samples, where present, demonstrate only isolated controls. Backend implementation is on hold; no completed end-to-end outcome or stakeholder approval is claimed.

  1. 03Current UI review: follow the navigation as far as the explicitly available screen; the complete feature below is not built. Stop when the named control is absent.
  2. 04Planned acceptance — Review the planned settings list and the unresolved allowed-setting decision.
  3. 05Planned acceptance — change an approved fictional low-impact setting, inspect validation/preview and confirm the change.
  4. 06Planned acceptance — Reload to compare effective and recorded values, then restore the prior value through a reversible change.
  5. 07Planned acceptance — Attempt an unapproved key or out-of-scope change and verify denial with no secret or security-policy exposure.

Backend work for this feature

Requirements only · Backend implementation on hold

What needs to be supported

  • Define an allowlisted settings schema, scope, validation rules, defaults and explicit capability mapping; do not expose an arbitrary key/value administration API.
  • Enforce authorized keys/scopes server-side; keep secrets outside settings responses, ordinary storage and audit text.
  • Persist versioned proposed/effective values with actor/time/reason and expected-version checks; apply/revert atomically or show failure without claiming success.
  • Test effective-cache refresh, concurrent updates, invalid values and denied security-sensitive keys. No hosted configuration, auth policy, credential or deployment changes are performed now.

How to verify when implementation is approved

  1. Test assigned settings capability versus ordinary admin/reader access; reject unapproved keys and cross-scope writes.
  2. Submit invalid and stale/concurrent changes; verify unchanged effective state or one accepted version with a clear conflict.
  3. Apply and revert an approved synthetic setting; verify effective reads and audit history after reload without secret values.

Before this can work

  • Choose the Robin Park dummy account and open its assigned Platform administrator Home without a password or authenticator prompt. This dev-only Home review does not verify MFA or unlock protected staff actions. Use your own provisioned staff account and authenticator when reviewing those actions.
  • Choose the initial safe settings, their owner and impact/confirmation rules before implementation. Security, authority, credentials, billing and deployment remain separately approved operations.
  • Use fictional role-preview records. Frontend prototypes may simulate the workflow; no backend implementation or real service operation is authorized.

Connected stories