Prisma1: Better handling of permission definitions

[do4gr]

The new syntax to input permission queries has some known limitations and also uncovered some bugs in the former implementation. These are going to be fixed soon.

I'm documenting them here until they are fixed:

• actually validate permission queries on create and update against the permission schema
• validating the queries against our new convention for naming them in the CLI
• disregard filepath changes in the diff to not trigger unnecessary delete/creates
• when no permission query file is sent by the CLI a normal permission is silently created, it should throw an error

[kbrandwijk]

Just one thing, regarding:

if query name not unique in yaml definition (t.graphql:same, t.graphql:same)

Why would that be an issue?

[marktani]

Agreed with @kbrandwijk, that should be supported.

[do4gr]

That was probably not worded precisely enough. If you have typename.graphql with two queries in it with the same name and you use the typename.graphql:queryName adressing in the yaml we will use the first one for both since we can't discern which one is which.

permissions:
- operation: User.create
   query: ./User.graphql:create
- operation: User.create
   query: ./User.graphql:create

query create {
   SomeUserExists
}

query create {
   SomeOtherQuery
}

We will throw an error on deployment of this constellation at some point.

[kbrandwijk]

@do4gr That's a different case. I (and I think @marktani too) were thinking about referencing the same query in multiple places in the project file. That should be supported. Naming two different queries the same would not be right of course.

[do4gr]

Ah ok, yes the use case you mention will be supported.

[kbrandwijk]

Also see https://github.com/graphcool/graphcool/issues/794 for another very valid validation use case from @FredyC.

[do4gr]

I added missing relations to my top comment of the known limitations. I'll update the top comment once the first fixes are rolled out.

[do4gr]

We rolled out several fixes that address permissions issues:

• Disregard comments when checking for permission changes to not trigger unnecessary delete/creates.
• It is now possible to reference the same query in the same file from multiple models and operations
• When two or more permissions are identical they can now be deleted all at once
• Error handling for the : addressing if query name not unique in query file or does not exist in file
• Fixed permissions being needlessly created and recreated
• Check for and disallow multiple colons in query path
• Check for and error if user creates a permission for a non-existing type or relation

I'll remove the fixed issues from the top comment.

[FredyC]

So I have just noticed it indeed reports an error when there is a permission for non-existing relation. Good job on that. However, it also spills out unformatted JSON with whole response payload. A quite scary sight for an untrained eye :)

[do4gr]

@FredyC Thanks for mentioning the formatting issue. That was unintentional. I'll adjust it to have the same formatting as other deploy errors.

[marktani]

This issue has been moved to graphcool/graphcool-framework.