Skip to content
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.

Permission error messages should include the name of the model that is invalid #592

Closed
joarwilk opened this issue Sep 26, 2017 · 5 comments
Assignees

Comments

@joarwilk
Copy link

joarwilk commented Sep 26, 2017

What is the current behavior?
Lets say I have a type name "Item" and I add a permission rule in my graphcool.yml file like this: - operation: Item.*.

Trying to deploy will print an error like this: ✖ unhandled error: Wrong operation defined for ModelPermission. You supplied: '*' since that rule is for relationships, not types.

The error message doesnt really help with debugging since it doesnt say which part of the configuration is failing. If you have a large schema trying to find the invalid rule will mean having to remove rules one by one until the error disappears.

What is the expected behavior?
If the error message would reference the name of the model that is failing, debugging would be a lot easier. Something like this:

✖ unhandled error: Wrong operation defined for ModelPermission. You supplied: 'Item.*'

@sorenbs
Copy link
Member

sorenbs commented Sep 26, 2017

Great point @joarwilk

Just to add that in the future we will support the wildcard permission for models. We just haven't gotten around to it yet :-)

@aurnik
Copy link

aurnik commented Oct 11, 2017

I'm getting the "Wrong operation defined for ModelPermission" even though the * is only on relations. Any idea what could be going wrong? I know some others on the forums were having this same problem.

@marktani
Copy link
Contributor

can you share a service definition that leads to that error?

@do4gr
Copy link
Member

do4gr commented Oct 20, 2017

We changed the error messages to now return the full operation definition. As proposed we now return Item.* instead of just *. For relations we included the check as well.

@do4gr do4gr closed this as completed Oct 20, 2017
@joarwilk
Copy link
Author

Yay, thanks @do4gr

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants