|
|
Django users |
Hi again, I seem to have come a cropper with this. Although it returns the projects = [project for project in Project.projects.all() if if I try do: projects = [project for project in 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 On Sun, Apr 13, 2008 at 12:56 PM, Tane Piper > values() seems to be the way to go for now. I've extracted some of > On Sun, Apr 13, 2008 at 11:59 AM, Malcolm Tredinnick > > On Sun, 2008-04-13 at 11:46 +0100, Tane Piper wrote: > > > What I want to > > Not really, unless you use values(). For any model, if the Python object > > > I'm sure there is a need for it when doing > > Login isn't the only time when the password hash might be needed (for > > It might make sense in your situation to just pull back the values() > > Regards, > > -- > -- > This email is: [ ] blogable [ x ] ask first [ ] private This email is: [ ] blogable [ x ] ask first [ ] private
fields I want on other models, on my Project model it seems to affect
it's functions and attribues For example, in this line:
project.get_permissions(request.user).view_project]
Project.projects.all().values('project_id', 'project_name') if
project.get_permissions(request.user).view_project]
exist. Any suggestions?
<digitalspaghe...@googlemail.com> wrote: --
> Hi Malcolm,
> 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.
> <malc...@pointy-stick.com> wrote:
> > [...]
> > > 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??
> > 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.
> > > authorisation, but once a session has been confirmed, is it needed
> > > again?
> > 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.
> > 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.
> > 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
Tane Piper
Blog - http://digitalspaghetti.me.uk
Skype: digitalspaghetti