sorry

let me make a playground

@tr33 https://play.authzed.com/s/9o3STtkgsPL9/schema

I only simplified one set

but there are other opportunities too

hm, but this schema would expose the "asset:hidden-2" to "user:sam" because she has "can_read" relationship on the top-most container

isn't that the intention?

the intended policy is "only the has can_read permission on assets that are 'hidden'"

so "hidden-1" and "hidden-2" should be visible only to user:fred (owner of the top-container )

but

owner

is inherited?

jep, "container" is meant to be some sort of folder structure

'owner' is something like 'admin' that can see all normal and hidden related objects down the graph

but 'editor' or 'viewer' can only read '*normal*' (aka parent) related objects on their level down

if a branch becomes "hidden"-related, the owners of the main branch keep the can_read permission on that hidden branch. for editors, the can_read permission should be gone

it acts like a trash can: only higher-ranking personnel are allowed to rummage through the dirty laundry in their departments

makes sense ?

yes

😄

I've been chewing on this problem for 2 days 🙂

let me see...

how do you plan to mark an asset as

hidden

?

change the relationship from asset#parent@container to asset#hidden@container

so it will always be

parent

or

hidden

?

never both?

indeed

k

well, having accidentally both relationships shouldn't break the system, but result in the same result as without the 'hidden' relationship

same goes for change on 'container': if its relationship is container:sub#hidden@container:parent only direct+indirect owners of "parent" should have can_read to the "container:sub" and its descendants - but not 'editors' or 'viewers' of container:parent

or in short: if any container/asset has a 'hidden' relationship in the hierarchy, only owners/parents-owners of that branch shall have 'can_read'

the complete branch shoud go "hidden" for non-owners (if 'hidden' is the only relationship)