-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AssociationResourceRouter limitations #363
Comments
I tried to stay away from these concerns, but with #370 I have bumped up against some.
In that case you couldn't use the
Ok, but don't. If you want a
Good example, but yes you can do that. The solution I put in so-far was to allow The much much more nuanced issue here is that you might want to have 1 queryset for the list, and a 2nd queryset for what you're allowed to associate. So yeah, you might want to list all tokens associated with the user, but you wouldn't want to allow the user to associate any token in the system. Because of that, yes, the related object viewset should allow for overriding 2 different methods - a filter_queryset method for the list, and a different (optional) method to filter queryset for purpose of association. I'm trying to make the default behaviors of this better in #370 I have considered an alternative criteria, maybe you have a thought on - if you have "change" permission to the parent object then you should be shown all related objects. This allows you to disassociate objects even when you don't have view permission to those objects. This may need to be configurable behavior. |
Bug Summary
This ticket exists just to track known limitations with AssociationResourceRouter.
This will some day motivate me to write a better router.
The current
AssociationResourceRouter
.../users/N/authorized_tokens/
and/users/N/personal_tokens/
you can't do that easily.The text was updated successfully, but these errors were encountered: