Making it easier to customise models saved by the admin (e.g. add an "updated_by" field)

[Simon Willison-2]

A very common requirement for customising the admin is to
automatically update a created_by or updated_by field with the user
object that made changes to an object. This is currently way harder
than it should be: http://www.djangosnippets.org/snippets/903/

That's not elegant at all - it involves hiding form fields with
JavaScript and cramming extra data in to form.cleaned_data before it
is processed by the regular admin flow.

We can definitely do this better by providing a new customisation
hook. I've added my first attempt as a ticket here:

http://code.djangoproject.com/ticket/8005

It's not quite right yet but it's a reasonable start. Here's the
resulting ModelAdmin subclass code:

class ArticleAdmin(admin.ModelAdmin):

    def save_model_add(self, request, form, formsets):
        new_object = form.save(commit=False)
        new_object.created_by = request.user
        new_object.updated_by = request.user
        new_object.save()

        if formsets:
            for formset in formsets:
                formset.instance = new_object
                formset.save()

        return new_object

    def save_model_change(self, request, form, formsets):
        new_object = form.save(commit=False)
        new_object.updated_by = request.user
        new_object.save()

        if formsets:
            for formset in formsets:
                formset.save()

        return new_object

The formsets stuff needs to be separated out to avoid unnecessary code
duplication, but I think it's the right general approach. Thoughts?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Julien Phalip-2]

That looks good, but it would be cool (and maybe simpler) to have
pre_save and post_save hooks. For example:

class ArticleAdmin(admin.ModelAdmin):

    def pre_save(self, request, instance, add):
        if add:
            instance.created_by = request.user
        instance.updated_by = request.user

Just a thought...

On Jul 28, 11:29 pm, Simon Willison <si...@...> wrote:

> A very common requirement for customising the admin is to
> automatically update a created_by or updated_by field with the user
> object that made changes to an object. This is currently way harder
> than it should be:http://www.djangosnippets.org/snippets/903/
>
> That's not elegant at all - it involves hiding form fields with
> JavaScript and cramming extra data in to form.cleaned_data before it
> is processed by the regular admin flow.
>
> We can definitely do this better by providing a new customisation
> hook. I've added my first attempt as a ticket here:
>
> http://code.djangoproject.com/ticket/8005
>
> It's not quite right yet but it's a reasonable start. Here's the
> resulting ModelAdmin subclass code:
>
> class ArticleAdmin(admin.ModelAdmin):
>
>     def save_model_add(self, request, form, formsets):
>         new_object = form.save(commit=False)
>         new_object.created_by = request.user
>         new_object.updated_by = request.user
>         new_object.save()
>
>         if formsets:
>             for formset in formsets:
>                 formset.instance = new_object
>                 formset.save()
>
>         return new_object
>
>     def save_model_change(self, request, form, formsets):
>         new_object = form.save(commit=False)
>         new_object.updated_by = request.user
>         new_object.save()
>
>         if formsets:
>             for formset in formsets:
>                 formset.save()
>
>         return new_object
>
> The formsets stuff needs to be separated out to avoid unnecessary code
> duplication, but I think it's the right general approach. Thoughts?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Brian Rosner]

On Mon, Jul 28, 2008 at 7:29 AM, Simon Willison <simon@...> wrote:
> The formsets stuff needs to be separated out to avoid unnecessary code
> duplication, but I think it's the right general approach. Thoughts?

Based on the patches on the ticket I think this is a good route.
However, if we do the main form we must also do the formsets. They too
can work with save(commit=False) along with a formset.save_m2m()
method. This is also something that has seen several tickets before.
Specifically [1] which requires this re-factoring to make it possible.

[1]: http://code.djangoproject.com/ticket/5780

--
Brian Rosner
http://oebfare.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Joseph Kocherhans]

On Mon, Jul 28, 2008 at 8:29 AM, Simon Willison <simon@...> wrote:

>
> A very common requirement for customising the admin is to
> automatically update a created_by or updated_by field with the user
> object that made changes to an object. This is currently way harder
> than it should be: http://www.djangosnippets.org/snippets/903/
>
> That's not elegant at all - it involves hiding form fields with
> JavaScript and cramming extra data in to form.cleaned_data before it
> is processed by the regular admin flow.
>
> We can definitely do this better by providing a new customisation
> hook. I've added my first attempt as a ticket here:
>
> http://code.djangoproject.com/ticket/8005
>
> It's not quite right yet but it's a reasonable start. Here's the
> resulting ModelAdmin subclass code:
>
> class ArticleAdmin(admin.ModelAdmin):
>
>    def save_model_add(self, request, form, formsets):
>        new_object = form.save(commit=False)
>        new_object.created_by = request.user
>        new_object.updated_by = request.user
>        new_object.save()
>
>        if formsets:
>            for formset in formsets:
>                formset.instance = new_object
>                formset.save()
>
>        return new_object
>
>    def save_model_change(self, request, form, formsets):
>        new_object = form.save(commit=False)
>        new_object.updated_by = request.user
>        new_object.save()
>
>        if formsets:
>            for formset in formsets:
>                formset.save()
>
>        return new_object
>
> The formsets stuff needs to be separated out to avoid unnecessary code
> duplication, but I think it's the right general approach. Thoughts?

I've thought about this quite a bit, and it's essentially the approach
I was taking, so +1

I also wanted to add a save_formset method to the InlineAdmin class,
but the details turned out to be a little too tricky to work out in
the hour or so I had to spend on it.

Joseph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---