Closed Mapiarz closed 1 year ago
Perhaps the HasRetVal
is not meant to be used in this case? After reading the docs this is my understanding:
HasRetvalPerm
provides an example for a field that requires the user to have a specific permission to view the product. This check is applied after the field is resolved, making sure the user has permission to see the resolved product.
HasPerm
provides an example for a mutation, which checks if a user can create a product by checking if the user has the required permission before executing the mutation.
I believe the permission check using HasRetvalPerm
is probably happening after the mutation's execution. The mutation is creating the object and then checking permissions on the resultant object (return value). This could explain why the object is being persisted even if the permission check fails.
Yeah well it seems that the transaction rollback for the update/delete mutations that I was seeing is not really intended behavior. It's not meant to be used with mutations, really (which is a bummer). In fact, the HasRetvalPerm
is very limited in how you can apply it. It's either for single object instances or lists if you use django-guardian.
Maybe in the future we can have a mechanism which allows us to rollback the transaction after a resolver has exited.
Maybe in the future we can have a mechanism which allows us to rollback the transaction after a resolver has exited.
As I mentioned on discord, feel free to send a PR adding such a feature and I'll gladly review it :)
Ping me there if you need help on writing it
Describe the Bug
I have a mutation like this:
I make a request and get a response like this:
Yet the actual object has been created and persisted in the DB. I have tested further and update and delete mutations seem to be working correctly and abort the transaction if the permission check fails.
System Information
Upvote & Fund