Hi again,
I seem to have come a cropper with this. Although it returns the
fields I want on other models, on my Project model it seems to affect
it's functions and attribues For example, in this line:
projects = [project for project in Project.projects.all() if
project.get_permissions(request.user).view_project]
if I try do:
projects = [project for project in
Project.projects.all().values('project_id', 'project_name') if
project.get_permissions(request.user).view_project]
I get this error:
'dict' object has no attribute 'get_permissions'
I have tried passing it as a field but it comes back that it doesn't
exist. Any suggestions?
On Sun, Apr 13, 2008 at 12:56 PM, Tane Piper
<[EMAIL PROTECTED]> wrote:
> Hi Malcolm,
>
> values() seems to be the way to go for now. I've extracted some of
> the code back to a context variable, and anything within a view I'll
> just have to try and make it as efficient as possible, while still
> removing the user object from the context.
>
>
>
> On Sun, Apr 13, 2008 at 11:59 AM, Malcolm Tredinnick
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, 2008-04-13 at 11:46 +0100, Tane Piper wrote:
> > [...]
> >
> > > What I want to
> > > know is there any way I could simplify the method and have it remove
> > > the password field any time a user object is being selected as part of
> > > a related query??
> >
> > Not really, unless you use values(). For any model, if the Python object
> > is being constructed, it pulls back all the values it needs to populate
> > the attributes. The password hash is an attribute of the User model.
> >
> >
> > > I'm sure there is a need for it when doing
> > > authorisation, but once a session has been confirmed, is it needed
> > > again?
> >
> > Login isn't the only time when the password hash might be needed (for
> > example, it's displayed and editable in the admin screen) and it would
> > be quite hacky to introduce a special case for saying when that field
> > shouldn't be displayed. You're using the User object in public-readable
> > situations, which isn't really part of the design. So change your design
> > a bit so that you're not throwing around this information if you don't
> > want it displayed. Yes, anything can be serialised using json, but that
> > doesn't mean you should indiscriminately do so or that the framework
> > should accommodate that.
> >
> > It might make sense in your situation to just pull back the values()
> > that you need for various objects and serialise that dictionary. Or you
> > could make another pass through the projects list and blank out the
> > attribute(s) you aren't interested in, such as _project_manager_cache.
> >
> > Regards,
> > Malcolm
> >
> > --
> > A clear conscience is usually the sign of a bad memory.
> > http://www.pointy-stick.com/blog/
> >
> >
> > > >
> >
>
>
>
>
>
> --
> Tane Piper
> Blog - http://digitalspaghetti.me.uk
> Skype: digitalspaghetti
>
> This email is: [ ] blogable [ x ] ask first [ ] private
>
--
Tane Piper
Blog - http://digitalspaghetti.me.uk
Skype: digitalspaghetti
This email is: [ ] blogable [ x ] ask first [ ] private
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
