Flock record access

#Flock record access

Flock scoping has been removed. A flock no longer reaches a record by having its id written onto that record. It reaches a record through a share, the same mechanism that hands one record to one person.

If you are here from an older link, a bookmark, or a search result that promised a crew_id column and three filter variables — this page is the replacement, and the short version is at the top of the next section.

Flocks are crews in the API and your Nest is a project there; the API spellings below keep those names.

#What used to exist, and what replaces it

The old way (removed)	What to use now
A crew_id column on the collection's table	An item share naming the flock
Row scope crew on the collection's Access panel	Row scope All or Their own, plus shares for the exceptions
The "Filed by flock" preset	Whichever preset fits, then share
$CURRENT_USER_CREWS and its two siblings in a filter	Nothing — a share is not a filter variable
security.crew_isolation: admin_full	Nothing — Nest admins reach every record
A member's admin place in a flock	The manager tier (a rename, in storage as well as in labels)

Saving a collection policy that still names any of the removed spellings answers 400 with the code crew_reach_removed and a message naming shares. It is refused rather than quietly dropped, on purpose: a filter that stopped resolving would invert under not and not in, turning "only my flocks" into "every row in the collection".

#Why it changed

There were two answers to "which flock can see this record", and having two was the problem.

Flock scoping was a mark on the record: one flock per row, set when the row was written, applying to a whole collection at once. Sharing is a grant beside the record: any number of flocks or people per row, granted by whoever owns it, at whatever level it needs.

Sharing does everything scoping did and several things it could not — a record can reach two flocks, a flock and a person, or a flock at read while another edits. Keeping both meant every read path, every write path and every audit surface had to agree about two mechanisms instead of one, and the places where they disagreed were where records became visible to people who should not have seen them. So the older one is gone. (The full reasoning is ADR 0004.)

#How to get the old behaviour

The thing flock scoping was usually reached for — "the Coastal Volunteers have survey notes and the Rangers must never see them" — is now built like this:

1. Give the collection the row scope Their own on the roles that write to it. Records are private to whoever created them by default.
2. Share each record — or the whole set, as you create it — with the flock, at the level that flock needs: read, edit, or manage.

What each member may then do is the share's level capped by their tier in the flock. A manage share to a flock still gives an editor in that flock no delete. That capping is where a member's tier does its work; the tier grants nothing on its own.

A share is per record, so this is more deliberate than a collection-wide setting — which is the point. It is also visible: System → Access shows every share a flock holds, where the old column showed only a value in a row.

#For an operator upgrading an existing instance

An instance that never used flock scoping needs no action. One that did has to clear it before updating, because the migration that removes the feature refuses rather than converting anything on your behalf. The commands, the exact error, and how to read what it objected to are in updating an EmuView instance.

#What did not change

• Flocks themselves. Creating them, inviting people, tiers, capability roles, the whole of managing flocks is untouched.
• security.crew_isolation still governs whether a Nest admin may manage a flock they are not in. It lost only admin_full, which controlled a row filter that no longer exists.
• super_admin reaches everything, and a never-rule is still the one thing that binds it.
• Membership changes apply on the next request. Accepting an invitation, leaving a flock, or a change of tier clears that member's session cache.

#Testing what a flock can see

Unchanged, and more useful now that there is one mechanism to trace: System → Access → Effective Access or GET /api/v1/access/simulate?crewId=… evaluates the real permission engine for a flock, and GET /api/v1/access/explain traces a single decision gate by gate. Both are described in access control.