Re: [PATCH datacenter-manager] ui: auto-installer: allow multi-select of installation entries

["Christoph Heiss" <c.heiss@proxmox.com>]

Thanks for the review!

On Fri Aug 28, 2026 at 12:57 PM CEST, Lukas Wagner wrote:
[..]
> I think the UX could be improved a bit. Right now, it's a bit weird that
> *any* click on the row automatically selects it. For instance, when
> going through entries one by one to show the "System Information", this
> is a bit annoying, since one cannot press the 'System Information'
> button if multiple entries are selected.
>
> I think this could be solved in two ways:
>
>   - Require the user to explicitly enable 'bulk-select', e.g. by
>     pressing a button or ticking a check-box in the header. Before doing
>     so, the checkbox column could be hidden
>
>   - Patch 'DataTable' so that only a click on the checkbox selects the
>     entry, but not when clicking anywhere else. This probably needs to
>     be configurable, not sure if we don't break other UIs if we do that.
>
>
> I think the first option could be the preferable one.

Makes sense. I'll see and will try out what works and fits better.

I also guess we don't have that pattern of UI somewhere else yet, which
could be taken as reference?

[..]
>>              Self::Message::RemoveEntry => {
>> -                if let Some(key) = self.selection.selected_key() {
>> +                self.spawn({
>>                      let link = ctx.link().clone();
>> -                    self.spawn(async move {
>> -                        if let Err(err) = delete_entry(key).await {
>> -                            link.show_error(tr!("Unable to delete entry"), err, true);
>> +                    let selection = self.selection.clone();
>> +                    async move {
>> +                        for key in selection.selected_keys() {
>> +                            if let Err(err) = delete_entry(key).await {
>> +                                link.show_error(tr!("Unable to delete entry {key}"), err, true);
>> +                            }
>>                          }
>
> I guess in most cases a 'bulk-remove' API endpoint is preferable, mostly
> to at least *enable* atomicity at the API level. But since removing
> installations ends up removing individual files any way, which is
> inherently not atomic, I guess the current approach is fine as well.

Yeah, thought about that too - but kept it simple here on purpose (as
you described) for now.

>
> If we ever end up storing installations in something that supports
> atomic operations (say, a sqlite DB or a single JSON file), a
> bulk-delete endpoint can be added as well.
>