On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote: > > Joseph Kocherhans wrote: > > >Create a ForeignKey field that references > >django.contrib.auth.models.User or whatever. This field cannot be > >editable=False, or the manipulator will skip over it when you save the > >object. Exclude the field from your admin screens using the fields > >attribute of the new inner Admin class. At this point, the user field > >is techincally editable, but not displayed. Then, the admin add/change > >views (controller in your terminology) call a method of the inner > >Admin class to set the correct user in new_data or something before > >the manipulator validates and saves it. The details obviously need to > >be worked out, but I think this is a pretty clean solution. Nothing > >changes but admin views, and the inner Admin class. No more coupling. > > > > > This will work only in Admin but authentication generally isn't tied to > it. I recall that people in django-users were interested in automatic > user assignment to work in any view and they didn't want to insert > "SomeModel.created_by=request.user" in every view. It's expected to work > just like auto_now fields. > > My first thought were that instead of > > new_data=request.POST.copy() > > we could do > > new_data=request.get_post_data() > > which would return a dict-like object but also with attribute "user" set > to "request.user". The manipulator then may use it to populated > "auto_created_by" and "auto_changed_by" fields. > > But now I don't like it either since it ties core to Auth which is > optional. Thoughts?
I don't like get_post_data() as a method of request. I think it would would be cleaner if it was a method if the inner Meta (or posibly inner Admin) class. In that case, Meta.get_post_data() *could* ask all the fields to modify new_data, kind of like the context processors in ticket #1164. Something like a display=False/True attribute for fields in addition to editable=False/True would be convenient here, as often times you'll want to display all but one or two fields. What would really be nice is callable defaults that can also update new_data. It would take care of the auto_add/auto_add_now stuff as well. auto_add/auto_add_now and auto_created_by/auto_changed_by could be handled with a callable default and a new allow_updates=True/False (or something) attribute on fields. auto_add/auto_add_now could disappear then. Joseph
