I'm not sure that we are understanding one another. In an earlier post you mentioned the phrase "current user". I interpreted that to be the user which had "logged in" to the site, using django.contrib.auth (such as to be able to use the admin, though certainly not all such users need be given admin privileges).
I further got the impression that this wasn't the user referred to by the user field of your RoomMate model. Though perhaps that is what you wanted to store in the user field. I couldn't really tell from what you have written. It is possible to get the logged in user object from the request object, as previously described. Whenever that's the user you want, that's how you should get it. django provides a significant amount of mature code in order to make this work, and doing it over for yourself will only cause you heartache. I don't think that you need to add anything to the session. At most, I would store the current user's id there, assuming that you have any better access to the session object than you do to the request object at the point of usage. If I'm interpreting the code correctly, I think that it is a bad idea to modify a class attribute of the User class (get_profile) as part of your save method. Perhaps you should instead perform a get_or_create directly in the if send_mail block, for one user, the other, or both, instead. Then anything that depends on the operation of user.get_profile in your code will work for both of that or those users. But the portion of the code you supplied does not seem to use get_profile, so either you don't need to do this at all, or this isn't the right place to do it. A way to pass the request user into a form or model form that sends email on save is to add it to the __init__ arguments and save it in an instance attribute. The view that instantiates the form must then pass that argument, since the view has access to the current user as request.user. Less clean would be, after instantiating but before using the form, store the current user on the form instance. If, on the other hand, you are trying to send mail from a model's save method, this is nasty, and any solution you try that involves global or the equivalent of C's static class variables will create subtle bugs related to threading in deployment. My best advice is to limit actions in a model's save method to a combination of validation and database related actions (such as modifying or saving other models), all of which can be rolled back in the event of a database error. >From your original code posting (whose indentation and line breaks are messed up by the time it reaches my email reader) is, I presume for your RoomMate model, which is NOT the same as django.auth.user, yet both the 'inviter' and the 'invitee' have a user instance, the first being the current user, and the later being the target of the RoomMate instance's user field. If that's the case, then the RoomMate model still shouldn't have first_name, last_name, and email fields, since the corresponding information is in either the user object or the request.user object. If a RoomMate object is really just a relation between an inviter and an invitee, plus inv_date and is_registered, then wouldn't it be a better design to have inv_date, is_registered, and two foreign keys on User, one called inviter and one called invitee? On Tue, Jul 20, 2010 at 4:36 PM, reduxdj <patricklemi...@gmail.com> wrote: > I'll try storing my current user's data to the session. By the way, is > this a limitation or > part of the django security model? What limitation are you talking about? -- 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.
