Proposal: change to the way list_editable form data is submitted in the admin

[John C]

Hey,

For the past five years, I've been using Django to manage a database of online applications. I absolutely love it! Makes my job so much easier.

In general, any problems I run into, there's usually an easy workaround. But I wonder if that's even feasible in this case. Anyway, here's the problem: in managing submissions we make a lot of use of the list_editable attribute of ModelAdmin, particularly for status columns. It's extremely handy to be able to load up a list, filter it, and then make status changes to selected records all in one go.

However, there are times when these status columns are also changing on their own, due to what's happening on the front end. I have to be very careful to ensure that this doesn't happen in between when I load an admin list and when I click "Save." If so, then I may end up overwriting the newly changed data, back to what it was when the list was loaded in my browser. This is because all rows are always saved, based on the data in the form inputs from the list.

I propose that a copy of the list_editable values be sent along as a hidden form element (or, alternatively, that Javascript be used to detect values changed in response to user input). That way, in the admin form handler, only rows that have been intended to be changed would be updated to submitted values.

It adds some complexity, sure, but are there any disadvantages I haven't thought of? From my perspective, it would solve a rather frustrating problem.

Thanks,

John Cronan

[Josh Smeaton]

I know this particular case has been discussed before. Here are two related tickets (I think there's a better canonical ticket but I can't find it just now): https://code.djangoproject.com/ticket/11652 and https://code.djangoproject.com/ticket/16549

I haven't done the required reading recently, so I can't comment on whether or not your idea could be accepted. But hopefully those tickets should provide a bit more information for investigation puproses.

[John C]

Thanks. #11652 is a good description of the same problem in the context of the "change" page. I think that, in practice, it is more of a problem with a list_editable, since you're updating many records at once. This makes a "collision" with some other part of the system more likely.

I think the approach outlined in #16549, which requires persisting a version number, would suffice but is not really necessary. I can understand wanting to make the solution applicable more widely than just one particular admin feature; however, the best solution depends on the context. In the case of #11652, optimistic locking is a good fit, because we can't assume the granularity of the different fields on the model. Whereas with list_editable, it's a bunch of records of the same type. It is quite safe to assume that we can consider the records that were updated by the user, compared to the values originally displayed, and do all these changes independently of one another. From this point of view, it is actually an optimization, to skip the update when there is no change.

-John

[Collin Anderson]

I could see this feature being helpful. (Submitting the original data and comparing it to be sure we don't silently have a merge conflict).

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1f970804-7b49-44da-916f-21270e4a3cac%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.