so you can define a caveat like "is_the_correct_day_of_week", then write the expected day of week with the relationship itself

and at check time, give the current day of week

I think that “context at write time” is what I’d like to learn more about. I’d expect the writers to have that context, but not the readers. Continuing with your example - is there a way to write the day of the week one time per day rather than pass it in on every read? Does that make sense?

so let's a somewhat more concrete example: a user can only access something if their IP is in the correct CIDR range

so we might define a schema like so:

definition user {}

caveat allowed_ip(user_ip ipaddress, allowed_ip_range string) {
  user_ip.in_cidr(allowed_ip_range)
}

definition document {
  relation reader: user with allowed_ip
  permission view = reader
}

you could pass both the user's IP and the allowed range at check time

or, you might want to say "this particular user is only allowed given range 1.2.3.0"

if the latter

when you write the relationship, you'd give that range as well:

CREATE document:firstdoc reader user:ethan[allowed_ip:{allowed_ip_range:"1.2.3.0"}]

so now

user:ethan

is always gated on that allowed IP range

at

CheckPermission

time, you'd have to specify

user_ip

(the user's current IP); if you don't, you'd get back a

PERMISSIONSHIP_CONDITIONAL_PERMISSION

because we can't know for sure whether

user:ethan

has access without the current IP

When would something like this happen while trying to write relations?

{
 "type": "Error",
      "message": "2 UNKNOWN: unable to find revision: ERROR: column \"id\" does not exist (SQLSTATE 42703)",
      "stack": ...
}

It seems to happen at random, and might go away if I make the same call again. I'm running spicedb with the operator

What datastore type are you using?

postgres. running an instance on rds I started at 1.13 and upgraded to 1.14 recently by changing the docker image being used in the operator. I don't know if I need to run any migrations manually?

You need to run “spicedb migrate head” to migrate the database

We’re working on upgrading the operator to do it automatically

How can we change the access_token of API frequently due to compliance reason?

With Caveats, can we create relationships like, users are only allowed to create 10 documents per week, or admins can set certain folders to "read only" which prevents edits to their child documents

Hi. I’ve got a question: the documentation on schema definition mainly talks about permissions and relations for an object. However, what if my objects have properties.

How do we define properties for the objects?

For instance if we define a user object, what if I have properties like “imported: true|false”? Or like an object like “server” having multiple properties like “environment: dev|qa|prod” and “os: Ubuntu|Windows 10|RHEL 7” and “owning_department: HR|Finance|Sales”

i am just visiting here. not a part of the development team. hence, i can only tell you how i did this. i store users internally, in my database, however i store them. i use SpiceDB for permissions. the identifiers for SpiceDB objects and subjects are my records ids [primary keys]. i populate SpiceDB using the equivalent of:

zed relationship create organization:1 owner user:2
zed relationship create event:1 organization organization:1

Only, except for the records that I want seeded [dummy test data], instead of

zed

, which is CLI tool, I use the SpiceDB API.

yes; you just pass that state in at CheckPermission time

it depends on how you intend to use these in your permissions checks; typically, you'd create objects to represent the environment or os, etc, and walk through them to grant/remove permissions

I see, you mean, "no. Of documents in a week" as a state need to be passed during check permissions ?

yes

you could write it on a relationship too, but you should only do that if you don't expect it to change all that often

My understanding is , max. no we will have to set up with create relationship, and during check will have to paas current state. If current state reaches 11, permission check shall return false

yes, that's the preferred way to do it