all lists on lists.proxmox.com
 help / color / mirror / Atom feed
* [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
@ 2026-05-28  9:26 Shannon Sterz
  2026-05-28  9:44 ` applied: " Lukas Wagner
  2026-05-28  9:54 ` Thomas Lamprecht
  0 siblings, 2 replies; 6+ messages in thread
From: Shannon Sterz @ 2026-05-28  9:26 UTC (permalink / raw)
  To: pdm-devel

Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
---
 ui/src/remotes/auto_installer/token_panel.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ui/src/remotes/auto_installer/token_panel.rs b/ui/src/remotes/auto_installer/token_panel.rs
index 3732ffe..0ee5afc 100644
--- a/ui/src/remotes/auto_installer/token_panel.rs
+++ b/ui/src/remotes/auto_installer/token_panel.rs
@@ -218,6 +218,7 @@ impl LoadableComponent for AuthTokenPanelComponent {
                         All existing ISOs with this token will lose access!"
                     ))
                     .disabled(self.selection.is_empty())
+                    .dangerous(true)
                     .on_activate(link.callback(|_| Message::RegenerateSecret)),
             )
             .with_flex_spacer()
-- 
2.47.3





^ permalink raw reply related	[flat|nested] 6+ messages in thread

* applied: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
  2026-05-28  9:26 [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous Shannon Sterz
@ 2026-05-28  9:44 ` Lukas Wagner
  2026-05-28  9:54 ` Thomas Lamprecht
  1 sibling, 0 replies; 6+ messages in thread
From: Lukas Wagner @ 2026-05-28  9:44 UTC (permalink / raw)
  To: pdm-devel, Shannon Sterz


On Thu, 28 May 2026 11:26:18 +0200, Shannon Sterz wrote:
> 


Applied, thanks!

[1/1] ui: auto-installer: mark regenerating auto installer tokens as dangerous
      commit: fe21265a0e860314ef63ca116e02ece020f59a67

Best regards,
-- 
Lukas Wagner <l.wagner@proxmox.com>




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
  2026-05-28  9:26 [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous Shannon Sterz
  2026-05-28  9:44 ` applied: " Lukas Wagner
@ 2026-05-28  9:54 ` Thomas Lamprecht
  2026-05-28 10:02   ` Lukas Wagner
  2026-05-28 10:04   ` Shannon Sterz
  1 sibling, 2 replies; 6+ messages in thread
From: Thomas Lamprecht @ 2026-05-28  9:54 UTC (permalink / raw)
  To: Shannon Sterz, pdm-devel

Thx for the patch and the quick apply. FWIW this is missing commit
message body and none added on applying, a short sentence here would
be appreciated.

Am 28.05.26 um 11:25 schrieb Shannon Sterz:
> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
> ---
>  ui/src/remotes/auto_installer/token_panel.rs | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ui/src/remotes/auto_installer/token_panel.rs b/ui/src/remotes/auto_installer/token_panel.rs
> index 3732ffe..0ee5afc 100644
> --- a/ui/src/remotes/auto_installer/token_panel.rs
> +++ b/ui/src/remotes/auto_installer/token_panel.rs
> @@ -218,6 +218,7 @@ impl LoadableComponent for AuthTokenPanelComponent {
>                          All existing ISOs with this token will lose access!"
>                      ))
>                      .disabled(self.selection.is_empty())
> +                    .dangerous(true)
>                      .on_activate(link.callback(|_| Message::RegenerateSecret)),
>              )
>              .with_flex_spacer()

IMO a bit borderline, as this is not like a classic API token where this
causes active service disruption.
OTOH. setting that flag hasn't that big of an impact and doesn't really
hurt either, so fine. I'd just avoid using it for everything that can be
framed as destructive, as most things with a confirmation prompts might be,
as then it looses the punch a bit (or could again just be the default).
But when implementing these yesterday I also could not come up with a
definitive rule that always holds, so certainly not a clear cut - just
wanted to avoid that we use this to liberally now - as said, here it was
OK to do (except the short missing rationale).




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
  2026-05-28  9:54 ` Thomas Lamprecht
@ 2026-05-28 10:02   ` Lukas Wagner
  2026-05-28 10:26     ` Thomas Lamprecht
  2026-05-28 10:04   ` Shannon Sterz
  1 sibling, 1 reply; 6+ messages in thread
From: Lukas Wagner @ 2026-05-28 10:02 UTC (permalink / raw)
  To: Thomas Lamprecht, Shannon Sterz, pdm-devel

On Thu May 28, 2026 at 11:54 AM CEST, Thomas Lamprecht wrote:
> IMO a bit borderline, as this is not like a classic API token where this
> causes active service disruption.

ack, FWIW, I checked what we do for classic API tokens, and while it's
of course not the exact same thing, it seemed similar enough to use the
same semantics here.

> OTOH. setting that flag hasn't that big of an impact and doesn't really
> hurt either, so fine. I'd just avoid using it for everything that can be
> framed as destructive, as most things with a confirmation prompts might be,
> as then it looses the punch a bit (or could again just be the default).
> But when implementing these yesterday I also could not come up with a
> definitive rule that always holds, so certainly not a clear cut - just
> wanted to avoid that we use this to liberally now - as said, here it was
> OK to do (except the short missing rationale).

I'll make sure to ask for a more detailed rationale in the commit
message next time, or add one myself if done easily enough!





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
  2026-05-28  9:54 ` Thomas Lamprecht
  2026-05-28 10:02   ` Lukas Wagner
@ 2026-05-28 10:04   ` Shannon Sterz
  1 sibling, 0 replies; 6+ messages in thread
From: Shannon Sterz @ 2026-05-28 10:04 UTC (permalink / raw)
  To: Thomas Lamprecht, pdm-devel

On Thu May 28, 2026 at 11:54 AM CEST, Thomas Lamprecht wrote:
> Thx for the patch and the quick apply. FWIW this is missing commit
> message body and none added on applying, a short sentence here would
> be appreciated.
>
> Am 28.05.26 um 11:25 schrieb Shannon Sterz:
>> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
>> ---
>>  ui/src/remotes/auto_installer/token_panel.rs | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/ui/src/remotes/auto_installer/token_panel.rs b/ui/src/remotes/auto_installer/token_panel.rs
>> index 3732ffe..0ee5afc 100644
>> --- a/ui/src/remotes/auto_installer/token_panel.rs
>> +++ b/ui/src/remotes/auto_installer/token_panel.rs
>> @@ -218,6 +218,7 @@ impl LoadableComponent for AuthTokenPanelComponent {
>>                          All existing ISOs with this token will lose access!"
>>                      ))
>>                      .disabled(self.selection.is_empty())
>> +                    .dangerous(true)
>>                      .on_activate(link.callback(|_| Message::RegenerateSecret)),
>>              )
>>              .with_flex_spacer()
>
> IMO a bit borderline, as this is not like a classic API token where this
> causes active service disruption.
> OTOH. setting that flag hasn't that big of an impact and doesn't really
> hurt either, so fine. I'd just avoid using it for everything that can be
> framed as destructive, as most things with a confirmation prompts might be,
> as then it looses the punch a bit (or could again just be the default).
> But when implementing these yesterday I also could not come up with a
> definitive rule that always holds, so certainly not a clear cut - just
> wanted to avoid that we use this to liberally now - as said, here it was
> OK to do (except the short missing rationale).

ack, i'll add a rationale next time.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous
  2026-05-28 10:02   ` Lukas Wagner
@ 2026-05-28 10:26     ` Thomas Lamprecht
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Lamprecht @ 2026-05-28 10:26 UTC (permalink / raw)
  To: Lukas Wagner, Shannon Sterz, pdm-devel

Am 28.05.26 um 12:01 schrieb Lukas Wagner:
> On Thu May 28, 2026 at 11:54 AM CEST, Thomas Lamprecht wrote:
>> IMO a bit borderline, as this is not like a classic API token where this
>> causes active service disruption.
> ack, FWIW, I checked what we do for classic API tokens, and while it's
> of course not the exact same thing, it seemed similar enough to use the
> same semantics here.

Actually I went back and forth a bit on exactly those yesterday, less because
of impact but more as each such sets basically a precedent ^^ But ultimately
decided that it's probably fine to err on the side of caution, especially on
removals and also with the not so big UI/UX impact here; that's why it's
also fine here.

So all good, just wanted to give slightly more context of my thoughts here.
And btw. my trigger for changing the confirm prompt in the first place was
the flashy red error icon that sprung into me when opening the "apply pending"
subscription prompt the first time after getting some distance from testing it
and me then thinking "wait, did I press a delete button".




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-05-28 10:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-28  9:26 [PATCH datacenter-manager] ui: auto-installer: mark regenerating auto installer tokens as dangerous Shannon Sterz
2026-05-28  9:44 ` applied: " Lukas Wagner
2026-05-28  9:54 ` Thomas Lamprecht
2026-05-28 10:02   ` Lukas Wagner
2026-05-28 10:26     ` Thomas Lamprecht
2026-05-28 10:04   ` Shannon Sterz

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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal