Skip to main content
Access Policies have the same structure in v1, except for how a policy names what it grants. This guide covers that change and what it means for updates. The changes every endpoint shares are in What changes in v1.

​
Routes

​
Grants

An app’s grants move from permissions, identified by requestable-permission ID, to entitlements, identified by entitlement ID. A v1 body looks like this:
v1 body
Requestable-permission IDs stored from v0 don’t work in entitlements. Migrate requestable permissions to entitlements covers the change from requestable-permission IDs to entitlement IDs. Grants covers app-level grants and the checks Lumos runs on each ID.

​
Updating a policy

Send only the fields that a write body takes. To send a read back in Update Access Policy, first remove the policy’s id, and the label on each app and entitlement. v1 returns 400 for a field that a write body doesn’t take. v0 ignored those fields.

​
Status values

status takes lowercase values, in responses and in request bodies. A v0 value returns 400. Drafts, publishing, and enabling covers what each status allows.

​
Conditions

v0 saves any condition. v1 checks each condition when you save it, and returns 400 for one it can’t evaluate, such as a misspelled attribute or a date without a time zone. What Lumos rejects has the list. A policy whose stored condition names a deleted custom attribute fails the same check. To change anything else on that policy, send Patch Access Policy without access_condition. v0 ignores access_condition when is_everyone_condition is true. v1 returns 400, unless access_condition is the everyone condition a read returns. Conditions on the Access Policy object covers both fields.

​
Terraform

In version 1.x of the Lumos Terraform provider, lumos_access_policy names grants by entitlement ID and takes lowercase status values, as v1 does. Migrating from 0.x to 1.x maps each attribute.