Preview the site as a guest — and leave feedback on it
See the signed-out site — or any persona's site — without signing out, so the experience most visitors have is one you can annotate.
Owned by Venue Manager · 14 steps · about 12 minutes
Why this exists
The feedback overlay needs a session. An anonymous visitor gets no overlay at all, by design. But the signed-out page genuinely differs from the signed-in one — an event offers Log in to buy instead of Reserve, the member and staff nav groups vanish, member-only sections disappear — so the experience most visitors actually have was the one experience nobody on the team could leave a note about.
Preview closes that gap. Your session keeps its real identity and its real feedback tools, and the page is drawn as somebody else.
The invariant: preview changes what is rendered, and nothing else
Your account and your groups are loaded from the real session and are never touched. Every permission check, every service call, every API response and every write runs with your real rights, in preview or out of it. An admin previewing as a guest still passes every admin API call.
The persona reaches exactly one place — the template context — and it can only subtract or restate what is drawn. There is no mechanism by which it could grant anything. Read that as the safety guarantee it is: previewing as an admin does not make you one, and previewing as a guest cannot lock you out of your own session.
Who may preview, and why the bar is where it is
venue_manager and above. Reviewing the site is a staff job, and a member must not be able to produce a screenshot of a fake staff page even cosmetically. door_staff sit below the bar — a manager implies door staff, not the other way round. Leaving preview is deliberately not gated at all: getting out must always work.
If your grants are revoked while a preview is open, it goes inert immediately — the persona stops applying on the very next page. A just-demoted account keeping a cosmetic staff view for the rest of its session is exactly the spoofing the bar exists to prevent.
Gated pages render the persona's real outcome, in place
Drawing the real member hub wrapped in guest chrome would be a screen that exists nowhere in the product, and notes about it would be notes about a fiction. So a page the persona could not reach is replaced by a page that states plainly what they would get: the sign-in wall for a guest, or a forbidden page naming the group they lack. The URL does not change, the preview bar stays, and there is an inline button to leave preview and open the page for real.
The status code is always 200 — this is our page describing a simulated outcome, not the outcome itself. Real 404s are never substituted: a missing page is missing for everybody, and re-dressing one would hide a genuine failure.
Where the state lives, and why it is not a link
Preview is stored per session, not per user and not in the URL. A shareable preview link would put a reader into a mode they never asked for, on a URL they believe is the real page. A per-user setting would stop you keeping a real window and a preview window open side by side. And because it hangs off the session, preview ends at logout is true by construction rather than by a hook somebody could forget.
Before you start
- A venue_manager or admin session. Members and door staff cannot enter preview.
- Nothing else. Every page of the app can be previewed.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| venue_manager | manager@club.test | manager123 | the lowest role that may preview; admin implies it |
| admin | admin@club.test | admin123 | owns the gate-decision tool and the preview audit trail |
Steps 1–11 — Venue Manager
their manual →-
1From any page, open the site menu and look directly under the Signed in as line. That is where View as… sits: one primary button for Signed-out visitor, plus a chip for each of the other personas.Expected result A persona switcher inside the menu, right under your own account line.Watch out for They are buttons, not links. Entering preview is a state change, so it is a form post with a CSRF token — you cannot bookmark it, and you cannot send it to somebody.
-
2Enter preview as the signed-out visitor.Expected result The page reloads with a magenta bar pinned to the top, tagged PREVIEW, naming the persona in caps and showing your real email beside it.Watch out for The bar is deliberately nothing like the amber demo banner, and it sits above it. If you cannot see it, you are not in preview — check before you file a bug about the page you are looking at.
-
3Read the events list as a guest. The member and staff nav groups are gone; so is anything the catalogue only shows to a signed-in visitor.Expected result The public catalogue, in public chrome, at the same URL.Watch out for You are still you. Your rights have not changed — only the drawing has. If a page still shows you something staff-only, that is a real bug worth a note, not the preview leaking.
-
4Open a single event. This is the page the feature was built for: a guest is offered Log in to buy where a member gets a reserve action.Expected result The signed-out purchase path, exactly as a first-time visitor meets it.Watch out for This is the highest-value page to annotate, because it is the one every visitor sees before they have any reason to trust you.
-
5Now try a page a guest cannot reach. The URL stays; the page is replaced by a plain statement that a signed-out visitor would be sent to the sign-in wall.Expected result A 200 page describing the outcome, carrying the preview bar and an inline button to exit preview and open the page for real.Watch out for The sign-in wall is the guest experience for everything under the member and admin areas. It is worth annotating — a bad sign-in wall loses more people than a bad events page.
-
6Leave a note on what you are looking at. The feedback pill and the whole overlay stay live while you are previewing — that is the entire point of the feature.Expected result A numbered marker, exactly as on any other page.Watch out for The overlay belongs to whoever is really signed in, which is why it survives the signed-in chrome disappearing. Losing it while previewing as a guest would make the feature pointless.
-
7Find the note in the review queue. It carries an as guest pill in its location cell.Expected result The note tagged with the persona you were previewing when you wrote it.Watch out for That tag is written from the server's own record of your session state, never from anything the page sent. Without it, 'the buy button is missing' is ambiguous in the worst possible way — either a bug, or a correct rendering of the page the author was reading.
-
8Open the note. The header repeats the pill, a sentence explains what it means, and the location table carries a Viewed as row.Expected result For a note written in your own view, that row reads 'the author's own view'.Watch out for The JSON export carries the persona; the CSV export deliberately does not, because its column list is frozen. Use JSON when you need provenance in a machine-readable form.
-
9Switch persona without leaving preview, from the switcher in the bar itself or from the feedback drawer's View this page as… row.Expected result The same URL, redrawn as the new persona.Watch out for The drawer entry exists because somebody who has just opened 'leave feedback on this page' is exactly the person who needs to ask what a signed-out visitor sees. On a phone the bar collapses to persona and exit only — use the drawer for the full switcher.
-
10If you are wiring this into a tool of your own, read the state as JSON: whether you may preview, whether one is active, the persona list and the minimum group.Expected result A small JSON object; inert for anybody below the bar.Watch out for It reports the live answer, re-checking your grants rather than trusting the stored row. A preview whose owner has lost the right reads as inactive here.
-
11Leave preview with the ✕ on the bar when you are done.Expected result The bar disappears and you are back on the same page as yourself.Watch out for Exiting is not group-gated — it always works, even if the grant that let you enter has been revoked in the meantime. Logging out also ends it, because a preview cannot outlive the session that started it.
Steps 12–14 — Admin
their manual →Owns the gate-decision tool and the append-only audit of who previewed what.
-
12When somebody asks 'why did that page block for a member', ask the gate directly: give it a path and a persona and it shows the decision and the reason.Expected result The verdict — allowed, needs a session, or needs a group it names.Watch out for The decision is read off the route's own declared dependencies, not a hand-kept path-to-group table that could drift away from the real authorization. Anything it does not recognise renders normally, so the mechanism can only over-hide, never over-reveal.
-
13Read the preview state: your own, every open preview on the platform, and the recent audit entries.Expected result One row per enter, switch and exit, with actor, session, personas, page and IP.Watch out for That audit is append-only and registered read-only with the data suite — you cannot tidy it up, and neither can anybody else. It is the answer to 'who was looking at the site as an admin last Tuesday'.
-
14Know the one conservatism in the gate. A page guarded by 'host of this event' blocks the host persona whenever the event on screen is not the one the persona is scoped to.Expected result A blocked page where you might have expected a rendered one.Watch out for It is over-hiding on purpose. The alternative — guessing which event a persona should count as host of — is how a preview starts showing somebody a page they could not really open.