On Aug 9, 8:46 pm, Collin Grady <[EMAIL PROTECTED]> wrote:
> group_obj.user_set.all() /is/ available :)
Doh. I forgot about the _set thing...
Moral of the story: don't code if you've not slept for 36 hours
--
Richard
--~--~-~--~~~---~--~~
You received this me
Hi guys,
I'm just wondering if there is a rationale for leaving off the
related_name attribute on the 'groups' field for the User model.
I can't think of a reason against this? Surely it would be beneficial
to have group_object.users.all() available?
--
Richard
--~--~-~--~~---
On Jul 6, 6:05 pm, PoBK <[EMAIL PROTECTED]> wrote:
Ah crap... Wrong list. Sorry folks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
I've got a case for passing an object between various components
within my framework.
The basic concept is similar to the way Mod_Python does things, where
I can add an attribute to the request instance and that attribute will
persist accross the current request only irrespective of which handler
On Jan 16, 6:42 pm, Scott Paul Robertson <[EMAIL PROTECTED]> wrote:
I use LDAP a bit differently. Using the LDAPBackend in ticket #2507
works rather well for me. When I wrote the patch, I understood that to
use the current auth system means to make User objects. I for one was
happy with this bec
On Jan 11, 11:36 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
* The real thing we've been discussing, though, is a way for apps to get ahold
of users after they've been created by a third-party authenticator. For
example, on my sites I'm gonna want everyone to have a username whether they
u
Erm,
I've just refreshed my django install to rev 3954 (per object
permissions branch) and deiscovered that model inheritance seems to
work...
Is this right? Have you guys secretly injected model inheritance back
into the distro? Or is the per-object-permissions branch running from
an old versio
