In a permission query, is the `$node_id` variable ...
# prisma-whats-new
w
In a permission query, is the
$node_id
variable available for CREATE permissions? I thought it was, and according to the documentation it is, but on the right-hand side where all the available variables are listed, it doesn't show up.
a
@wallslide Permission queries run before the object is created, so $node_id would be highly unlikely...
w
I swear they used to have it. Otherwise, how would I say "Only allow users to create an event that they are an owner of" If I can't target the specific event-to-be created's ID?
It basically says: check if a user exists that has id = [currentuser] and id = [owner field in Event you are trying to create]. You don't need the ID of the object you're trying to create for that
It's still a bit contrived... But it works...
w
Thanks, I'm trying to see if I can get this to work... 😅
a
You need to draw it on a piece of paper. Queries are not the best way to compare two values. You want to say: [currentUser] = [event.owner], but because you can only use a query, you have to take that detour to someUserExists...
w
first attempt failed:
Copy code
query ($input_eventId: ID!, $user_id: ID!) {
  SomeEventExists(filter:{
    id: $input_eventId,
    owner: {
      id:$user_id
    }
  })
}
a
Maybe a permission query is not the best place to do that, maybe a transform_argument event hook is easier?
No, you have to do it the other way around
Event doesn't exist yet
w
hrmm, I figured a nested mutation would create the
Event
, then try to create the nested
Location
object
so then the
Event
object would exist
a
Is this the permission query on Event, or Location?
w
Location
Users can have many events, which can have one location
a
What permission are you trying to create, in English?
w
Allow the user to create a location, if it is pointing to an event that they are an owner of
I'm doing a
createEvent
mutation, which has a nested mutation in it that creates its connected
Location
at the same time
I know that if I open up the
Location
query permission to everyone, then the
createEvent
mutation goes through fine. So I'm working backwards now, trying to get this
Location
query permission working.
a
You could also set the permission on the relationship
w
But that would let them create unrelated
Location
nodes, which I don't want
a
Not if the relation is required (you should test that though)
w
I don't think you can require relations yet
oh, as of 4 days ago it looks like it might have been implemented
a
Yes, it was quite recent
w
I'll try that route then. I still wish I knew why the above query was failing though
a
Your query is correct, it might have to do with the internal execution order of nested mutations, but that's something @nilan might be able to answer.
Documentation says nested mutations are split up into 'multiple isolated mutations', so maybe it creates the location first, then the event, then connects the two internally. I have no idea.
w
yeah, I'm eager to hear @nilan 's take on this
thanks for your help!
a
If you split the mutation, does the permission query work then? That would be a great test
So in the playground, first create the event, then a separate mutation to create the location with the relation to the event
If the permission query on location works well then, then it's definitely due to the way nested mutations are handled.
I'm curious if that's the case actually, can you test it?
w
just tried this query:
Copy code
query ($eventEvent_id: ID!, $user_id: ID!, $locationLocation_id: ID!) {
  SomeEventExists(filter: {
    id:$eventEvent_id,
    owner: {
      id: $user_id
    },
    location: {
      id:$locationLocation_id
    }
  })
}
and got a
No CONNECT permissions
error
I'll try to create them separately and see what happens
👍🏻 1
a
Yes, because if the connect permission query is showing the same sh*t as the location one, it must have something to do with the handling of the nested mutation
w
Creating them separately worked
Now I'm going to get rid of that connect permission, and see if my original query works
a
Great news!
w
The original query seems to work as well
a
That's what I thought, because it looked right
w
So it's an issue with nested mutations and permission queries
a
Yes, can you create a new issue? https://github.com/graphcool/api-bugs/issues/new
w
yeah
👍🏻 1
That's too bad... basically if I want to work around this problem I have to separate every nested mutation I have in my project
a
Or wait for a day, and ask @nilan how soon that might be fixed.
w
yeah, or wait. Hopefully it's an easy fix
🙏 2