The Admin Surface and Step-Up Authorization

Overview

StretchProjects runs on two surfaces. The workspace surface is what your team uses day to day, and its writes are authorized by your ordinary signed-in session. The admin surface manages agency-owned data like the master roadmap, and its writes are protected by step-up authorization. This guide explains what that means and how to work with it.

Workspace vs. admin

Most customers only ever use the workspace surface and never see an admin prompt.

Why writes ask for your password

On the admin surface, every write — create, edit, move, delete — is a protected action. When you perform one, StretchProjects asks you to re-enter your admin password. This isn't a login that timed out; it's a deliberate step-up check that authorizes just that one action.

How the action token works

1. You start a protected write (say, moving a roadmap card).
2. StretchProjects prompts for your admin password.
3. On success, it mints a short-lived, single-purpose action token good for that one action.
4. The action is performed and the token is discarded — it is never stored.

Because the token is single-use and short-lived, an everyday session can't silently make protected changes, and a captured session token can't be replayed to alter agency-owned data.

The read gate

Some admin views may show a "Read-only — pending step-up authorization" banner instead of data. This is the read side of the same gate, not an error or a broken page. The views and endpoints are wired and working; data populates once read access is granted to your session. If you see this on the admin surface, it's expected behavior for gated boards.

Working smoothly with the gate

1. When prompted, enter your admin password and complete the action.
2. If you cancel or mistype, the action is not performed — nothing partial is saved.
3. On a board, a write that isn't authorized won't persist; a moved card will revert to its original column with a message explaining why.
4. Watch for the confirmation banner after each action — green for success, red with the reason on failure.

Example

An administrator reorganizes the master roadmap. They drag a card from Planned to Ready; StretchProjects prompts for the admin password. They enter it, the move completes, and an activity event records it. A moment later they try another move but dismiss the prompt by accident — that card snaps back to Planned with a note that authorization was cancelled. They redo the move, complete the prompt, and it sticks.

Tips

• Have your admin password handy when doing a batch of roadmap changes — each protected write re-checks it.
• If a card reverts, look at the banner: it names the reason (cancelled prompt, wrong password, or a network issue).
• A read-only banner is a gate, not a bug — don't refile it as broken; request read access for your session.
• Do sensitive planning on the admin surface and client-facing work on the workspace surface so the right authorization applies.

FAQ

Is my admin password stored when I authorize an action?
No. It's used to mint a one-time, short-lived token for that single action, and nothing about it is retained.

Why doesn't the workspace surface ask for my password on every change?
Workspace writes are authorized by your signed-in, org-scoped session, which is sufficient for your own organization's data. The extra step-up protects agency-owned data on the admin surface specifically.

I completed the prompt but my change didn't save.
Confirm the confirmation banner was green. If it was red, it names the cause; retry the action and complete the authorization. Then click Refresh to resync the board.