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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.