> > isEditable=0 > > login=0 > > Assuming these two previous lines are at the top-level of you class > statement, both attributes will be class-attributes (that is "shared > by all instances"). I don't think this is what you want. Yes but that's what I intended. They should (and do) not all have the same value, but every instance of the object should have access to the user. Ideally I would have a static user class holding the current user (or global variable), but unfortunately I could not get that to work.
> > def editable(self): > > if self.login==0: return False > > else: > > if self.isEditable!=0: return self.isEditable > > if self==self.login.get_profile(): > > Are you sure you want to compare the current whatever instance with a > profile ??? Nope, absolutly not :-). That should mean self.user instead of self. In the company self is right since it extends the user, but here I changed it. > > self.isEditable=True > > for o in self.offer_set.all(): o.editable=True > > Such a side-effect is really really bad practice (and, in this case, > mostly useless). I agree it's kind of bad. > > return True > > else: > > self.isEditable=False > > return False > > Code depending on the request.user should either takes an user as > param or live elsewhere. I will put it somewhere else. I guess you mean because the code is re- used twice. > > (I added the isEditable attribute to cache if the object is editable, > > since I wasn't sure if get_profile() is lazy loaded or sends a request > > to the db with each iteration) > > When you aren't sure, check, don't wildguess. Will do as soon as I am a little more used to Django. > > Yes that sounds possible. Just wondering if there is a cleaner way to > > do it - the ideal way would of course every object having access to > > the user in some way, but that seems impossible. > > Indeed. How would your code work in another environnment (command line > tool for example) else ? There it worked fine (the original version, as you stated this one had a bug). So it really must be the a different queryset. > wrt/ "a cleaner way to do it", your business rules are not clear > enough to come with a sensible answer. What I am trying to archive is rather simple - I just did not figure out a simple and clean way to do it: I have the company and offer objects. Each offer belongs to a company which belongs to a user. Whatever user is logged in should see an "edit" link on the live site, whenever his own company or offers come up. Anoynmous users should not see any edit links. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
