public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Lukas Wagner <l.wagner@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] Revert "ui: dc: remove notify key from datacenter option view"
Date: Tue, 9 Apr 2024 15:07:15 +0200	[thread overview]
Message-ID: <fc9cab02-e312-4805-a96b-d80234ef0439@proxmox.com> (raw)
In-Reply-To: <20240209101628.76377-1-l.wagner@proxmox.com>

Am 09/02/2024 um 11:16 schrieb Lukas Wagner:
> This reverts commit c81bca2d28744616098448b81fa58e133d3ac5ed.
> 
> In the first iteration of the notification system, notification
> routing and enabling/disabling notifications was configured via
> the (extended) `notify` parameter in `datacenter.cfg`.
> Because of that, the configuration UI for this parameter was moved to
> a new panel as a part of the notification UI.
> When changing to the newer approach for notification routing (matcher
> based), the "new" panel this setting was moved to was dropped from the
> UI.
> 
> Notification sending for package updates is still influenced by this
> parameter (see bin/pveupdate, line 55), so there should be a way to
> configure this from the GUI. At some point, the `notify` parameter
> should be dropped, but that'd be a thing for a major release.
> 
> Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
> ---
> https://forum.proxmox.com/threads/package-update-notifs-not-working.141182/
> 
> Notes:
>     Alternatively, we could just *always* send package update
>     notifications and just ignore that parameter from now on but this
>     might leave users wondering who have previously set
>     `package-updates=never`...

I'd propose two changes:

- add a hint to redirect users to the new mechanisms so that a future
  deprecation would be more expected (if we already plan that now)

- only show it if defined? While that's a bit magic, it'd avoid that
  users set it, but rather use the new mechanism.
  If, I'd never delete the setting via the UI, so that it doesn't
  suddenly disappears if one switches it from some value to default.

What do you think?




  reply	other threads:[~2024-04-09 13:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-09 10:16 Lukas Wagner
2024-04-09 13:07 ` Thomas Lamprecht [this message]
2024-04-09 13:44   ` Lukas Wagner

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=fc9cab02-e312-4805-a96b-d80234ef0439@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=l.wagner@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal