Confusion about translating legacy policies to new relation tuples

[cipher001]

Hey all, I'm evaluating new version of Keto as I'd like to make an upgrade from a self-hosted legacy version to the latest version. However I'm a bit confused at translating policies to tuples.

Using the following data as an example:

{
  "id": "super-admin-pid",
  "description": "Super Admin Policies", // description seems to don't exist anymore
  "subjects": ["super-admin", "root-admin"],
  "resources": [
    "ns:project:project-1:person",
    "ns:project:project-1:person:*:documents",
    "ns:project:project-1:person:**",
    "ns:project:project-1:report:report-A",
    "ns:project:project-1:report:report-B",
    "ns:project:project-1:report:report-C",
    "ns:metric:**",
    "ns:data:*:status"
  ],
  "actions": ["**"], // can have other actions like: create, read, update, delete
  "effect": "allow"
},

Questions:

• Is it possible to use a wildcard character in the object(in tuple) to indicate everything under the "directory" (eg project, person, data in the above example)? As there might be an unknown number of objects at the time of creating the tuple. A direct example for this is "ns:data:*:status". If I'm understanding the new way of doing things correctly, I'd probably need to use a subject set for this ?
• Is it possible to use wildcard "**" to grant access to everything? (ie syntax for old policy is having a single item in "resources"
  with the values of "**" )
• If a particular object is deeply nested in some directory (eg ns:project:project-1:persion:documents:something:object), Is it the best if I grant access recursively to every upper directories to make the best use of subject set (and probably lesser headache with "Direct Access" as well as it's not scalable)?
• Is there any wild card relations to allow whatever-relation (as in matching all CRUD in the example)? I've checked the source code and there's a variable called WildcardRelation but it seems to be not referenced directly in keto project.

Apologies if dumb questions are asked, I'm still pretty new to the new concept.

[vinckr]

Hello @cipher001

Which version are you using and which version do you want to upgrade to?
Maybe this guide is relevant for you: Migrating policies from 0.5 to 0.6

[cipher001]

Hello, thanks for the help. The current version is 0.5 and I'm trying to upgrade to v0.12. I've read the guide but I'm still a bit uncertain how should I handle nested structure/directories as in my example. Should I treat them as simple string and divide them up with the colon delimiter (eg ns:project:project-1:report:report-A --Allow--> ns:project:project-1:report --Allow-->ns:project:project-1 so on and so forth) or are there some hidden feature that allows this kind of folder structure?

Also it seems there're no wild card characters/feature that's available for unlimited access for a certain level, is that correct? (eg ns:project:* allow access to all project resources)