Who may approve, and how the portal knows

Five switches on every door

A portal door carries five booleans: view, comment, approve, upload and download. The studio sets them when it issues the door, and a door asked for with no permissions is view-only. Each portal route declares the one permission it needs, and a wrapper checks the door before the route runs, so a route never has to remember to check.

Approve is the switch that matters for sign-off. The decision route requires it; a view-only or comment-only door cannot reach the route at all, and the answer is the same refusal a stranger gets. The portal page reads the door's permissions when it opens and hides what the door cannot do, so a client with a comment-only door sees the thread and no approve button rather than a button that fails.

View is deliberately not implied by the others. A door that can approve but not view is a mistake a studio can make through the API, and the product lets the view route refuse so the studio notices, rather than repairing it silently.

A project door or a client door

A door is pointed at one project or at one client. A project door sees that project and nothing else. A client door sees every project of that client. A door pointed at neither sees nothing, so it can decide nothing. Whether a given approval is this door's to decide is answered by the same rule read backwards: the approval sits on a task, the task on a project, and the door must be scoped to that project or to that project's client.

The project and the client a door points at are checked against the studio's own organization before the door is written, so a door can never be pointed across organizations, and a missing project or client answers not found rather than creating a door with a dangling reference.

The reminder job uses the same scope rule to decide which doors to nudge when an approval passes its SLA, so the door that is reminded is always a door that could act.

One door per person

A door has a label the studio chooses, such as the client's name, or one person at the client. When the studio issues a door for a client without saying more, the invitation goes to the client's own contact email and phone. When the door is for one person - the marketing manager rather than the billing address - the studio gives it that person's email or phone, and the invitation goes there instead.

For a stronger tie between the door and the person, a door can demand a one-time code by SMS or email on top of the link: six digits, five minutes, five attempts, and a resend allowed after a minute. A door can also cap the number of devices, from one to twenty. With a cap of one, a foreign device entering moves the door to itself and ends every other session at once; with a larger cap, only the oldest session ends. The same device is never kicked: a refresh or a lost cookie is not a punishment.

The studio's trail shows, per door, how many distinct devices have used it. A door meant for one person that shows six devices is a link that has been passed around, and the studio can revoke it and issue a fresh one in the same minute.

When the studio decides on the client's behalf

A producer can record a decision on the studio side as well, with the client's word in hand. The decision row then carries the producer's user id and an actor type of user. A decision from the portal carries an actor type of portal and no user id. The two are distinguishable in the feed and in the audit log forever, so 'the client approved' and 'we approved for the client' are never the same row.

Internal sign-offs - an approval stage a producer or a director clears - are the same mechanism with a studio member as the approver and the task's assignees as the people reminded when it waits too long.

Expiry, revocation and what the studio sees

A door expires after 30 days by default. The studio can set 1 to 365 days, or explicitly choose no expiry; an omitted value never leaves a permanent door open by accident. A revoked door refuses immediately. A revoked door shows as revoked rather than expired in the studio's list, because a studio that turned a link off wants to see that it did.

The studio side lists every door with its label, state, permissions, first opened, last seen, distinct devices and the count of client approvals recorded. Before that list existed the honest answer to 'has she opened it' was a phone call.

Issuing and revoking a door are audited, with the door's settings and never its credential. A denied entry is audited too, with the reason - not found, revoked, expired, or one-time code required - recorded for the studio and never shown to the person at the door, because a difference in refusals is an oracle for a guesser.

• Default door: view only, 30 days, invitation to the client's contact row.
• Approve requires the approve switch; the UI hides what the door cannot do.
• Scope is one project or one client; never across organizations.

Questions that keep coming up

Can two people at the client have different rights?

Yes. Issue one door per person, each with its own email or phone and its own switches. One can be comment-only and the other can approve, and the record names which door decided.

What does a client with a view-only door see?

The item and its status, and the thread if comment is on. No approve button, no upload area, no download link. The page only offers what the door may do.

Can a client see other projects?

A project door sees one project. A client door sees that client's projects. No door sees another client, the studio's client list, or the names of staff not involved.

How does the studio know a link is being shared?

The trail shows distinct devices per door. A door for one person showing many devices is the signal, and the studio can revoke it and issue a new one immediately.

Is a decision the studio enters for a client marked differently?

Yes. A portal decision carries the portal actor type and no user; a studio decision carries the producer's user id. The feed and the log keep them apart.