From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ui: backup job overview: add filter field
Date: Fri, 20 Sep 2024 09:22:36 +0200 [thread overview]
Message-ID: <147cbd5e-9ab5-4663-98c8-1cc10592a0cd@proxmox.com> (raw)
In-Reply-To: <6b1e39b7-3bab-413e-b018-b45d741e761e@proxmox.com>
after a quick debugging session we realized that if a backup job has no
selection, we need to handle that.
This is not a normal situation and I most likely had these after
deleting the VMs and removing them from the job config.
Inline where the fix can be placed:
On 2024-09-20 08:09, Dominik Csapak wrote:
> On 9/19/24 17:36, Aaron Lauterer wrote:
>> gave this a quick test spin and if I clear my search, the other backup
>> jobs that did not match don't show up anymore. So resetting seems to
>> be somewhat broken.
>
> interesting, tested here with chrome and firefox and it works fine.
> what exactly did you press/put in/etc. ?
>
>>
>>
>> On a more general level, the question is, if this approach will be
>> sufficient or if we don't want something in the direction of "show me
>> all backup jobs that cover this specific VMID". Which will need a bit
>> more logic. Then the question is, do we want to handle that in the
>> backend, where we already have it, or do we handle it purely in the
>> frontend where we will need to replicate the logic.
>>
>> For example, all VMIDs on a node. all VMIDs except the selected. VMIDs
>> in resource pools, ...
>
> Fair, as that would "really" fix the bug. Just for the record, I did decide
> for a 'front-end' only approach because,
>
> * less api calls/parameters to maintain
> * it probably solves most use cases (and searching inside pools/etc.
> could also be done here)
>
> If we'd want to have a more comprehensive vmid <-> backup job lookup,
> i'd probably put it into the VM backup panel itself, or maybe as an
> addition to this filter
> as an explicit way to search for a vmid
>
> no hard feelings either way though :)
>
>>
>> On 2024-09-19 16:30, Dominik Csapak wrote:
>>> so that users can easily search their jobs for comments, VMID and pool
>>> names, in case there are many backup jobs.
>>>
>>> This partially addresses #5721, since one can search for vmid when they
>>> are selected directly, but not when inside a pool. Still should be a
>>> useful addition for users with many backup jobs.
>>>
>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>> ---
>>> www/manager6/dc/Backup.js | 39 +++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 39 insertions(+)
>>>
>>> diff --git a/www/manager6/dc/Backup.js b/www/manager6/dc/Backup.js
>>> index 381402ca..a96eb5bf 100644
>>> --- a/www/manager6/dc/Backup.js
>>> +++ b/www/manager6/dc/Backup.js
>>> @@ -780,6 +780,45 @@ Ext.define('PVE.dc.BackupView', {
>>> '-',
>>> run_btn,
>>> '->',
>>> + {
>>> + xtype: 'textfield',
>>> + fieldLabel: gettext('Filter'),
>>> + autoEl: {
>>> + tag: 'div',
>>> + 'data-qtip': gettext('Filters by Comment, VMID or
>>> Pool name'),
>>> + },
>>> + triggers: {
>>> + clear: {
>>> + cls: 'pmx-clear-trigger',
>>> + weight: -1,
>>> + hidden: true,
>>> + handler: function() {
>>> + this.setValue('');
>>> + this.getTriggers().clear.setVisible(false);
>>> + },
>>> + },
>>> + },
>>> + labelAlign: 'right',
>>> + listeners: {
>>> + change: {
>>> + fn: function(search, val) {
>>> + search.getTriggers().clear.setVisible(!!val);
>>> + store.clearFilter();
here a
if (!val) {
return;
}
will fix the issue
>>> + store.filterBy((record) => {
>>> + let found = false;
>>> + for (const field of ['comment', 'vmid', 'pool']) {
>>> + if
>>> (record.data[field]?.toString().includes(val)) {
>>> + found = true;
>>> + break;
>>> + }
>>> + }
>>> + return found;
>>> + });
>>> + },
>>> + buffer: 250,
>>> + },
>>> + },
>>> + },
>>> noBackupJobInfoButton,
>>> '-',
>>> {
>>
>
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-09-20 7:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 14:30 Dominik Csapak
2024-09-19 15:36 ` Aaron Lauterer
2024-09-20 6:09 ` Dominik Csapak
2024-09-20 7:22 ` Aaron Lauterer [this message]
2024-09-20 8:29 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=147cbd5e-9ab5-4663-98c8-1cc10592a0cd@proxmox.com \
--to=a.lauterer@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox