is there a recommended approach to creating time-boxed permissions that automatically start on X date and/or end on Y date?

today: have a worker add the relationship when it becomes valid and remove it when it becomes invalid

caveats should remove the need for an external worker to add and remove once they are complete

Hi there, I'm using a spicedb instance for some e2e tests, but because I am creating relationships and then depending on them right away to check permissions I think I am getting a stale response from the cache causing tests to fail. Sub-second updates to the cache are not a requirement for us, so is best practice to just use fully_consistent for tests? We're spinning up a separate docker instance for these tests. Is there a way to configure the container to always use fully_consistent?

Try setting your revision quantization to 1 nanosecond

Although you should consider properly integrating zedtokens

I am using zedtokens (potentially incorrectly) ... writing up the example

definition user {}

  definition organization{
          relation admin: user
   }
      
   definition company {
          relation organization: organization
          permission edit_data = organization->admin
   }

we create the company/organization relation first and store the resulting zedtoken with the company and the organization/user relation after. When we use the token stored with the company it seems like that snapshot is not guaranteed to include the organization/user relation that was just created

correct, you would have to use the zedtoken from the latest permission mutation to capture all of the permissions affected

This might not be the best example - there are cases where we will not know which zedtoken was latest

so in this case you could store the zedtoken with the organization, and update it any time a user was added to the organization

but in reality, zedtokens are meant to protect data, and therefore a little bit of staleness in "hierarchical" structure shouldn't matter so long as the data being protected hasn't changed

Ok, I incorrectly made the assumption that when accessing a resource you want to use the zedtoken on the resource in question. When using inherited relationships/permissions I should use the zedtoken on the "higher level" resource

If we added an editor relation between company and user though, how would I determine which zedtoken to use?

using the zedtoken on the organization might not pick up the new company:x#editor@user:y relationship right?

Yeah that’s what I meant about putting it with the data. What is your “resource”?

for the example it's just company documents

the documents don't individually have permissions

so I view the company as the resource

Ah, then the Zanzibar way would be to have a single company zedtoken and update that any time any document was updated

But that wouldn’t fix your “stale for tests” problem

right, but i think the quantization solution is good enough for the tests problem

I can live with users not being able to access the document for a second after being given access

thanks for the help!

@Jwatton are you using the

serve-testing

command for your tests?

Not at the moment

you might find is helpful, since it sets up everything ephemerally for testing

and it creates a new isolated environment per token sent in

so if each of your tests generates a unique token, they get an "isolated" in-memory datastore