> Can we at least agree to put an id="..." onto the element wrapping
that list.
That seems pretty minimal. Do you want to open a PR so we can have a
look?
On Tue, 16 Aug 2022 at 21:58, Jacob Rief wrote:
> Can we at least agree to put an id="..." onto the element wrapping
> that list.
>
Can we at least agree to put an id="..." onto the 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
--
You received this message because
Week ending August 14, 2022
*Triaged: *
https://code.djangoproject.com/ticket/33902 - UniqueConstraint's
validation crashes with string expressions. (accepted)
https://code.djangoproject.com/ticket/33904 - Many-To-Many field is
deleted/ignored from internal JavaScript “filter” interface
אורי
u...@speedy.net
On Tue, Aug 16, 2022 at 3:55 PM 'Adam Johnson' via Django developers
(Contributions to Django itself) 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
The least intrusive change would be to add an id="..." to the -element
wrapping that list.
This at least allows me to add such a Javascript snippet into {% block
extrahead %}.
– Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers
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
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
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
>> 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 (
>
> 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
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 with every objects list, or we can add
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
Thanks Jacob.
We have the functionality of the selects working fine, it's just finding a
way to make it clear to the user that the selected options that are
filtered out are still in fact selected and will be sent as such in the
POST.
Thanks for the info though, I'll take look.
On
13 matches
Mail list logo
