-
Notifications
You must be signed in to change notification settings - Fork 148
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
Alternative to RulesModelBase
in DRF to manage dependency on this library.
#155
Comments
RulesModelBase
to manage coupling and dependency on this library.RulesModelBase
in DRF to manage dependency on this library.
After checking
which simply returns It seems this dependency could be easily isolated into a util class.
Which would make |
Yes, I'd happily accept such a change. However, is it possible to abstract away the whole |
@dfunckt if we define it in
This would be a breaking change, however, so we need to continue supporting the model mixin. I'm wondering is something like this could work:
And here there's the issue of precedence. For now the model mixin would have precedence to avoid any breaking changes. |
Sorry, I must be missing something -- why is it a breaking change? I'll need to look into the code, but from this discussion I understand that if
existing clients would not break. What do I miss? |
That option still keeps the dependency, although yes, it makes it much easier to move around it My idea was to take it a step further, and by default, remove the dependency of the Views and DRF Mixins from the Your suggestion already fulfils my biggest issue, so I would be happy with it :) Heres a bit more detail about the idea I had, with some iterations based on our discussion and being backwards compatible: # All auto permission mixins (both for DRF and Django views) inherit from this mixin
class BaseAutoPermissionMixin:
def get_perm(self, class, perm_type):
return "%s.%s_%s" % (class._meta.app_label, perm_type, class._meta.model_name)
def get_permission_for_model(self, model, perm_type):
try:
use_model_mixin_method = callable(model.get_perm)
except AttributeError:
use_model_mixin_method = False
if use_model_mixin_method:
perm = model.get_perm(perm_type)
else:
perm = self.get_perm(model, perm_type)
return perm
# For DRF
class AutoPermissionViewSetMixin(BaseAutoPermissionMixin):
# ...
# For views
class AutoPermissionRequiredMixin(PermissionRequiredMixin, BaseAutoPermissionMixin) |
Okay, I totally see the use-case and agree in principle that this would be great to have but I need to spend some time to check the existing code and your proposal in more depth. If you're keen to PR stuff in the meantime, feel free and we'll take it from there. |
Sure, I'll post a PR for this. Actually maybe I can make 2:
We can move the discussion there as well, since it's easier to discuss things with concrete code :) Thanks for taking the time and attention on this! Really appreciate it! |
@dfunckt The PRs should be read for a first review. |
I'm working on a Django DRF project, and while implementing the rules, I feel like inheriting from
RulesModelBase
creates a really heavy dependency on this library.I'm trying to make it so that the
rules
dependency only affects the views, and not go all the way to the models.From what I can gather, the views have access to the current user, and the objects. The predicates get both the user and the permission object as parameters, so it feels like it would be possible.
Has anyone dealt with similar issues than this?
https://github.com/dfunckt/django-rules#permissions-in-django-rest-framework
The text was updated successfully, but these errors were encountered: