Generic FK is NOT needed about django-guardian HOT 7 CLOSED

Permission has content_type, but no instance ID. I should perhaps have coffee before asking this, but how would you connect them to model instances?

from django-guardian.

Maybe I haven't stated this clearly enough.

We remove content_type. We do NOT remove object_pk.

We fix content_object so we remain backward compatibility. But we do NOT use generic foreign key as it is used right now.

from django-guardian.

Postponed till v1.1

from django-guardian.

Are there any performance gains to be had by implementing this change? Or, are we just trading DRYness for simplicity?

from django-guardian.

@bltravis I think it would be simpler the @lukaszb is suggesting. I found the duplication really confusing when I've looked at the models for the first time.

from django-guardian.

In fact, I have another suggestion. Any objections on removing the dependency from auth.Permission, and maintaining only the relation between BaseObjectPermission and ContentType?

I'm not sure of the implications but it seams a cleaner solution. The auth.Permission model was meant only for model-level permissions, and that is the meaning underlying its foreign key to ContentType. Overloading its meaning for object-level permissions can probably break other django features, no?

from django-guardian.

Closing, as it was already implemented. As for the last suggestion - it's not bad idea, however build-in Permission model has this automatic creation base on Meta.permissions which is pretty nice and we would need to re-implement this feature in guardian. Something we can think of for v2...

from django-guardian.