Permissions need a place.

Attendance and payments need different access

Agrithm records attendance, wages, advances, and payments within a farm. I defined separate permissions for these actions: a Supervisor can mark attendance, while an Accountant can manage payments.

That role is stored on the farm membership. It does not grant the same user access to every farm.

Separate membership from action permission

The farm service looks up an active membership using both the authenticated user and the requested farm. It then checks the requested permission against the role on that membership.

A missing membership returns a not-found response; a membership without the required permission returns a denial. The caller does not supply the role used for that decision.

Valid identity?
  -> Member of the requested farm?
    -> Allowed to perform this action?
      -> Read or write only within that scope

Keep the role differences explicit

The permission tests include the differences that are easy to blur: an Accountant can calculate wages and manage payments but cannot create workers; a Supervisor can edit workers but cannot manage payments.

I use the same permission list to expose allowed actions to the interface. Hiding a control is a usability choice; the farm service still makes the authorization decision.

Try the smaller policy in the lab

The portfolio demo lets you change the fictional role and requested farm, then attempt attendance or payment actions. A role that permits an action still cannot bypass the farm check.

That lab is entirely client-side and does not enforce access to real data. It is a way to inspect the decision; it is not evidence of production use or a security audit.