[pmg-devel] [PATCH pmg-api 1/1] fix #3450: api: add 'filter' parameter to queue DELETE endpoint
Stoiko Ivanov
s.ivanov at proxmox.com
Mon Sep 22 12:09:25 CEST 2025
Thanks for the patches, reviews and suggestions!
On Mon, 22 Sep 2025 11:18:10 +0200
Thomas Lamprecht <t.lamprecht at proxmox.com> wrote:
> Am 22.09.25 um 10:58 schrieb Dominik Csapak:
> > one high level comment and a few comments inline
> >
> > i get what you want to achieve here and this is what stoiko wrote in the
> > bugreport, but from an UX perspective this could be bad. Since the
> > mails shown on the gui might not match what will be deleted (e.g. new mails came in, in the meantime)
> >
> > would it maybe make more sense to have an approach with giving a list
> > of ids to the backend? (@stoiko ?)
>
> That would be safer, as long as it can also handle at least 1k of mails
> being processed I'd be fine with that.
>
> An alternative could be passing a cutoff timestamp from the newest mail
> selected along, but an explicit list naturally is slightly simpler to
> handle and to debug, so mostly just mentioning it for the sake of
> completeness.
looked at bugreport and the Queue GUI again - I think my idea back then
was:
* we already have a filter in the Deferred Mail panel
* adding a checkbox for selection of multiple mails + one for all mail
(that is displayed after the filter) and Removing the selected ones
should help most users who need to clear up a queue most.
AFICT - sending a list to the backend seems a sensible way to achieve that.
> high-level: would then be naturally also nice to have for
> delivering a (filtered) list of mails, or does anything speak
> against that?
That seems a worth-while addition as well!
More information about the pmg-devel
mailing list