Hi there, I'm changing an existing app to add support for private objects which are accessible only to certain users. In order to make it hard to accidentally leak private data in case we forget to update one or more places to use the new (privacy-aware) API, I've changed the plain manager (.objects) to return only public objects and added a new manager (.all_objects), which has the new API that takes a user and returns only the objects (including the private ones) the user is allowed to see.
The .all_objects manager is set as the default manager and I was under the impression that would be enough to avoid breaking any django features when used with private objects (e.g. validation of unique constraints, ModelFormSet, etc) as most things seem to use the default manager. However, I've just found that django.views.generic.create_update.lookup_object() (which is used in the update_object() generic view) uses .objects directly and because of that it doesn't work for my private objects. I'm now wondering if there's a reason for that function to use .objects directly instead of using the default manager. Also, if there is a reason for that, does anyone know of other things that won't work with my private objects? Thanks in advance! Guilherme -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
