View-as: support without a password
When a member reports something you cannot reproduce from your own account, view-as renders their workspace exactly as they see it. Your own identity never changes. You are looking through their window, not logging in as them.
- Open the Workspaces tab and pick a member.
- Give a reason (required, logged) and a time limit (1 to 60 minutes, 30 by default).
- The app reloads inside that workspace under that person's view, read-only, with a banner the whole time.
- Need to fix something in place? Enable editing (confirm, and the banner turns red). Exit when done.
Starting a session
Supply three things:
- The workspace and the member whose view you want.
- A reason, which is required and written to the log.
- A time limit, from 1 to 60 minutes (30 by default).
Two people are off-limits as targets:
- A member of a workspace you did not select. You can only view a user inside a workspace they actually belong to.
- Another operator. Platform admins cannot be viewed-as.
Read-only by default
A view-as session starts read-only, and that is enforced on the server. The api refuses writes for the whole session, so a stray click cannot change anything. It is not a UI courtesy that a determined action could slip past.
While a session is live, a banner rings the entire screen and sits across the top:
- Amber border in read-only mode.
- Who and where: it names who you are viewing and which workspace.
- Time left: it counts down.
- Enable editing and Exit buttons.
- When the timer runs out the session ends on its own and returns you to
/admin.
Arming write mode
- Press Enable editing. It asks you to confirm first.
- The banner turns red, so the color alone tells you edits are now real.
- Drop back to read-only at any time with Back to read-only, or leave entirely with Exit.
- Its own logged event. Turning on write mode is logged separately from starting the session.
- Attributed to you. Every change you make in write mode is attributed to you, not to the member.
The trail it leaves
View-as is built to be visible, not covert. Two records are written:
- In the target workspace's own activity feed: a line, so the workspace sees that an operator viewed it, why, and when. Arming write mode adds a second line there.
- In the operator console's View-as Log: an append-only list of every session (operator, target, workspace, reason, mode, request count, and the start, expiry, and end times).
Because the reason is mandatory and both trails are append-only, there is no way to look inside a workspace quietly.