[pmg-devel] [PATCH pmg-api 1/1] fix #3450: api: add 'filter' parameter to queue DELETE endpoint

[Hannes Laimer]

On 22.09.25 12:09, Stoiko Ivanov wrote:
> 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.
> 

yes

so the "all" would be for the paginated list, right? I am not sure if
having 10-20+ pages worth of mail is realistic here

> 
>> 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!
> 
> 
>