More user friendly delete confirmation template

[Jacob Rief]

Whenever a user attempts to delete an object inside the Django admin,

a delete confirmation page is shown. If the object to be deleted contains

many relations, the user is overwhelmed with a list of other objects to be

deleted together with the current object. Often those objects are just

internal relations the user never heard of, and this may be unsettling.

I therefore propose to hide those related objects behind a link named

"Show related object to delete"

If the user clicks on that link, the complete list of objects to be deleted is

expanded into the confirmation page. This also prevents having to scroll

down to the end of a potentially very long page in order to confirm the

deletion by clicking on "Yes I'm sure".

– Jacob

[Danilov Maxim]

Hi Jacob.

On the one side - you can override this delete_confirmation.html and delete_selected_confirmation.html I do it since dj 1.4

 

On the other side I am agree with Jacob - it can be in Django by default. – We can add “collapsed” div to wrap <ul> with every objects list, or we can add details/summary for that.

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

ma...@wpsoft.at

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e59f0771-cb65-4564-ace4-50a7ffd96cf6n%40googlegroups.com.

[Adam Johnson]

If the object to be deleted contains many relations, the user is overwhelmed with a list of other objects to be deleted together with the current object. Often those objects are just internal relations the user never heard of, and this may be unsettling.

I would argue that if the list of objects is "overwhelming" / "unsettling", then this is perhaps an indicator that the admin interface is being used beyond its intended scope. The admin is designed for site administrators, mostly developers. Yes, most projects seem to push it beyond that, but we can't make it something for all people.

Collapsing the list of to-be-deleted objects could also lead to cases of accidental removal of related objects. I think it's better to err on the side of overwhelming than hiding information.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/000001d8b16a%24d5c5f640%248151e2c0%24%40wpsoft.at.

[Danilov Maxim]

>> Collapsing the list of to-be-deleted objects could also lead to cases of accidental removal of related objects. I think it's better to err on the side of overwhelming than hiding information.

 

But sometimes It is very painful to delete whole list of sessions (database-backed sessions) (4mlo) or Django admin logs (66mlo).

 

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

ma...@wpsoft.at

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0JL9DqgnoFSehXd5D8d4DjzEzvhrUWwbw5wqUBQdDF3Q%40mail.gmail.com.

[Adam Johnson]

The admin interface is not designed for such mass deletions. When deleting millions of objects, it can be necessary to paginate the deletion to avoid exhausting the resources of your database server. I don't think it's suitable for a view to try and do this.

Btw in the case of sessions, use the 'clearsessions' management command: https://docs.djangoproject.com/en/4.1/ref/django-admin/#clearsessions . In the case of admin logs, I would use 'shell' with the ORM.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/000401d8b176%2405e12c90%2411a385b0%24%40wpsoft.at.

[Carlton Gibson]

These kinds of UI features are quite "maintenance-heavy" — they're hard to test, and fragile — and so can consume a lot of time in review, perhaps disproportionate, perhaps not. That on-top of Adam's points mean I'd lean to -1 to begin. Maybe that's not the final answer, but I'd look for another way first. (The particular change here isn't likely too difficult, but that's the opening bias)

Then as Maxim points out, this is already possible with overriding the template. 

But we don't really show how to do that. 

(I'm looking forward to Maxim's DjangoCon talk, partly for this reason.)

I wonder if a HowTo in the docs on patterns for customising the admin, beginning with the "The Admin is not your app" reminder, but showing how you might override a template or two, or add a rich JS widget to a form, or ... (there are a few kinds of use-cases that come up I think)... — would be a useful resource?

I've always had to search for a while each time I've wanted to do this in the past. 

To me this would seem like something we could add without needing to expand the built-in functionality too much. 

Kind regards, 

Carlton

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2ieJ1Yr6AvH3ZLcX7AhZw7Sk2jNrWOH5gctvs1dkBFYw%40mail.gmail.com.

[Jacob Rief]

On Tuesday, August 16, 2022 at 4:23:03 PM UTC+2 Carlton Gibson wrote:

Then as Maxim points out, this is already possible with overriding the template. 

That's what I did of course in the first place. It however turns out that you have to copy quite a bunch of boilerplate code, the complete {% block content %}, in order to add a tiny Javascript snippet.

Since Django templates can evolve considerably between versions, this can lead to other side effects after upgrading.

An alternative would be add a {% block objects_to_be_deleted %} around the list of objects-to-be-deleted. This at least would allow to simpler extend that template. 

I would argue that if the list of objects is "overwhelming" / "unsettling", then this is perhaps an indicator that the admin interface is being used beyond its intended scope. The admin is designed for site administrators, mostly developers. Yes, most projects seem to push it beyond that, but we can't make it something for all people.

Well Django-CMS is built around the Django-Admin user interface and its users typically are not site administrators. Moreover, why would Django offer

a sophisticated permission framework, if the only users being "allowed" to work with the Django-Admin are "site administrators".

Side note, if you're unfamiliar with Django-CMS: Whenever you delete a CMS-page, you also delete its page-titles, placeholders and their plugins, which can lead to a really long list of objects to be deleted.

– Jacob

[Jacob Rief]

The least intrusive change would be to add an id="..." to the <ul>-element wrapping that list.

This at least allows me to add such a Javascript snippet into {% block extrahead %}.

– Jacob

[אורי‎]

אורי

u...@speedy.net

On Tue, Aug 16, 2022 at 3:55 PM 'Adam Johnson' via Django developers (Contributions to Django itself) <django-d...@googlegroups.com> wrote:

Collapsing the list of to-be-deleted objects could also lead to cases of accidental removal of related objects. I think it's better to err on the side of overwhelming than hiding information.

When I delete a user in the admin, I see the objects that would be deleted too. This is very important and I don't want to collapse this list. There are usually about 5 objects to be deleted, and I want to see them all in the HTML. The current interface is perfect and I don't want to change it.

Uri Rodberg, Speedy Net. 

[Jacob Rief]

Can we at least agree to put an id="..." onto the <ul> element wrapping that list.

That would help me to add some JS and CSS to the overwritten delete_selected_confirmation template without

having to copy a huge block of HTML code from that template.

– Jacob

[Carlton Gibson]

> Can we at least agree to put an id="..." onto the <ul> element wrapping that list.

That seems pretty minimal. 🙂  Do you want to open a PR so we can have a look? 

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1bbb2f37-765d-4bcf-83d6-7ddc04dd5edcn%40googlegroups.com.

[Jacob Rief]

On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote:

> Can we at least agree to put an id="..." onto the <ul> element wrapping that list.

That seems pretty minimal. 🙂  Do you want to open a PR so we can have a look? 

Okay, will do that.

Any suggestions for a name? My proposal is id="deleted-objects".

– Jacob

 

[Carlton Gibson]

Sounds good. 

(You mentioned adding an additional template block. You could put that in a commit to look at as well if you think it's of value to you.) 

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5dd47fd5-adcb-4a28-934f-8d132c3c540cn%40googlegroups.com.