Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: Add more concise methods of specifying similar tuples in tests #193

Open
netthier opened this issue Nov 7, 2023 · 5 comments
Open
Labels
enhancement New feature or request

Comments

@netthier
Copy link

netthier commented Nov 7, 2023

Currently, all tuples must be written out fully, e.g.

tuples:
  - user: user:alice
    relation: member
    object: group:foo
  - user: user:bob
    relation: member
    object: group:foo

I noticed that to fully test a model, I had often specified multiple tuples where 2 of the elements were identical, e.g. assigning multiple users as members of the same group.
This feature request is for a way of specifying such groups of tuples more concisely, e.g. by including arrays in the tuple definition:

tuples:
  - users:
      - user:alice
      - user:bob
    relation: member
    object: group:foo

with the same optimally being possible for object[s]. Maybe allowing to specify multiple relations could make sense too, though I haven't had such a need yet.

@aaguiarz
Copy link
Member

What if we supported an object/relation/user hierarchy like the one below?

tuples:
   - group:foo
         - member
              - user:alice
              - user:bob

@netthier
Copy link
Author

Interesting, though since the config file is YAML I'd assume it would look like:

tuples:
  - group: foo
      - member:
          - user: alice
          - user: bob

However, this syntax wouldn't support specifying multiple objects or relations, which is something I'd also like to see.
What if I want to make a user a member of multiple groups in my tests?

@rhamzeh rhamzeh added the enhancement New feature or request label Dec 18, 2023
@aaguiarz
Copy link
Member

aaguiarz commented Jan 4, 2024

We could try to get smart and recognize the following syntax too:

tuples:
  - member 
      - group: foo
          - user: alice
          - user: bob

I'm thinking of using this format for scenarios where you want to use OpenFGA for infrastructure scenarios and you want to provide a YAML file that configures permissions. If we can get rid of the "user/object/relation" keywords it will look closer to a YAML configuration file.

@netthier
Copy link
Author

I made a mistake and accidentally provided invalid YAML in my last comment as well.
I'd prefer if the file would continue to be YAML-formatted without any custom syntax.
My originally proposed syntax would allow specifying multiple of each of user, relation and object, which doesn't seem to be possible with your proposal.
As example use cases, I want to be able to assign many users to many groups, assign a user admin permissions in many groups, or assign a user multiple permissions on some object. Those could look like this in my originally proposed syntax:

tuples:
  - user:
      - user:alice
      - user:bob
    relation: member
    object:
      - group:foo
      - group:bar
  - user: user:alice
    relation: admin
    object:
      - group:baz
      - group:qux
  - user: user:bob
    relation:
      - update
      - read
      - delete
    object: file:foo

@rhamzeh
Copy link
Member

rhamzeh commented Jan 11, 2024

I really like that suggestion @netthier as it allows us to be flexible and support multiple use csaes, so each can use it whoever they need.

Though maybe, we'd change the field names to the plural form when they are an array

tuples:
  - users:
      - user:alice
      - user:bob
    relation: member
    objects:
      - group:foo
      - group:bar
  - user: user:alice
    relation: admin
    objects:
      - group:baz
      - group:qux
  - user: user:bob
    relations:
      - update
      - read
      - delete
    object: file:foo
  - user: user:bob
    relation: deleter
    object: file:foo

On the CLI it would be easier, because we can either ignore or error out when a duplicate fields are set.

In VS Code having mutually exclusive fields may be harder to get done, but I don't believe that'll be a big issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Backlog
Development

No branches or pull requests

3 participants