Graphcool / graphcool-framework

Apache License 2.0
1.78k stars 130 forks source link

Not able to save permission query with relation variable #190

Open marktani opened 6 years ago

marktani commented 6 years ago

Issue by schickling Friday Sep 08, 2017 at 09:34 GMT Originally opened as https://github.com/graphcool/prisma/issues/450


Issue by lastmjs Wednesday Sep 06, 2017 at 15:37 GMT Originally opened as https://github.com/graphcool/api-bugs/issues/255


Every time we try to use a relation variable in our permission query, the permission query does not save. There are no errors in the GUI.

Here is the permission query on creation of our Assignment entity:

query ($input_courseId: ID!, $user_id: ID!) {
 SomeUserExists(
   filter: {
    id: $user_id,
     OR: [{
         ownedCourses_some: {
           id: $input_courseId
         }
       },
         {
         role:ADMIN
       }]
   }
 )
}

And here is the Assignment schema:

type Assignment implements Node {
  id: ID! @isUnique
  createdAt: DateTime!
  updatedAt: DateTime!
  title: String!
  course: Course @relation(name: "CourseOnAssignment")
  author: User! @relation(name: "AuthorOnAssignment")
  questions: [Question!]! @relation(name: "AssignmentQuestions")
  questionType: QuestionType! @defaultValue(value: MULTIPLE_CHOICE)
  concepts: [Concept!]! @relation(name: "AssignmentOnConcepts")
  quiz: Quiz @relation(name: "AssignmentOnQuiz")
  numCreateQuestions: Int! @defaultValue(value: 1)
  numReviewQuestions: Int! @defaultValue(value: 3)
  numResponseQuestions: Int! @defaultValue(value: 10)
  numGradeResponses: Int! @defaultValue(value: 3)
}

Whenever we save the permission query, the query does not save. When we reopen the modal that should show the saved query, we get this bug-filled query:

{
 SomeUserExists(
   filter: {
     AND: [{
       id: $user_id,
       OR: [{
         ownedCourses_some:{
           id: $input_courseId
           author: {
             id: $input_authorId
           }
         }
       },
         {
         role:ADMIN
       }]
     }]
   }
 )
}

I would expect the original query to be saved.

marktani commented 6 years ago

Comment by schickling Friday Sep 08, 2017 at 09:34 GMT


Comment by danmkent Wednesday Sep 06, 2017 at 15:43 GMT


I replicated the same behaviour. It looks similar to this old graphcool console issue so it may be a console rather than an api issue:

https://github.com/graphcool/console/issues/694

marktani commented 6 years ago

Comment by schickling Friday Sep 08, 2017 at 09:34 GMT


Comment by danmkent Wednesday Sep 06, 2017 at 15:49 GMT


I saved the permission query above in the console and then pulled the project in graphcool-cli. The broken version of the permission query was downloaded, so it's that version that is persisted.

marktani commented 6 years ago

Comment by schickling Friday Sep 08, 2017 at 09:34 GMT


Comment by lastmjs Wednesday Sep 06, 2017 at 15:58 GMT


If I can generalize the experience I just had, it looks like the permission still works after saving it, it's just the GUI that displays the permission query incorrectly

marktani commented 6 years ago

Comment by schickling Friday Sep 08, 2017 at 09:34 GMT


Comment by marktani Wednesday Sep 06, 2017 at 16:00 GMT


If I can generalize the experience I just had, it looks like the permission still works after saving it, it's just the GUI that displays the permission query incorrectly

that's also my understanding. we'll investigate this issue, I think it is a problem in the console.

marktani commented 6 years ago

Comment by schickling Friday Sep 08, 2017 at 09:35 GMT


Comment by danmkent Thursday Sep 07, 2017 at 07:31 GMT


I have looked again and it seems that graphcool-cli never pulls the query parameters for permission queries. I saw this in a pulled query:

{
 SomeUserExists(
   filter: {
    id: $user_id,
     OR: [{
         ownedCourses_some: {
           id: $input_courseId
         }
       },
         {
         role:ADMIN
       }]
   }
 )
}

and thought it was incorrect but looking at other pulled permission queries, they work in the same way, so I guess this is how it is supposed to work.

So this does look to be a console bug rather than a problem with the API