Re: [pve-devel] [PATCH common/cluster/qemu/container/wt/manager v7] add tags to ui

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 21/06/2022 um 11:19 schrieb Dominik Csapak:
> this series brings the already existing 'tags' for ct/vms to the gui:
> * tags can be edited in the status toolbar of the guest
> * existing tags will be shown in the tree/global search/resource grids
> * when editing a tag, a list of existing tags will be shown
> * by default, the color is (consistently) autogenerated based on the
>   text
> * that color can be overriden in datacenter -> options (cluster wide)
>   (edit window for browser local storage is TBD)
> * by default, the text color is either white or black, depending which
>   provides the greater contrast (according to SAPC)
> * this text color can also be overridden
> * there are multiple shapes available for the tree (see [0])
> * adds new 'admin' tags that need higher privliges, these can then be
>   used to enable features like 'inlude in backup by tag', etc.

I didn't find the permission semantics for non-admin tags when skimming
the series, but after thinking about it off an on again recently I figure
that it could be seen as quite problematic in general to even assign existing
tags, then visible in the resource view, if the user got only limited privileges
to a VM; and that it could be quite problematic for such users to create new
ones, allowing typo squatting, slurs, ...? to have ill effects to other users
or admins of the same system/cluster. I mean to a certain degree this can be
correlated to the permission semantics of the hostname, but still there's more
of them and they're way flashier.

One method could be (always talking about non-admin tags for now):

* allow unrestricted usage of those for users with Sys.Modify on / + the rights
  on the object to modify (i.e., for guests that would be VM.Modify on /vms/<vmid>)

* for users without the powerful Sys.Modify on / we could give the admins the decision,
  for example through a datactenter.cfg property that could work like:

  user-tag-privs: useable=<none|existing|free|list>[,list=<tag1;tag2;...>]
  
  Meaning:
  - useable=none -> only users with powerful Sys.Modify -> / can configure tags
  - useable=existing -> currently existing tags can be used, the list could be added
    as base-set (so that users that only got one VM can actually set some)
  - useable=free -> existing can be used freely and new ones can be added freely,
    the list would only act as base suggestion set.
  - useable=list -> well, the list reflects all allowed tags to use (independent
    if they exist for that users POV or don't).

This would be still orthogonal to admin:tags (as their purpose is to avoid users
adding a possible OK tag to a unwanted guest due to actions like backup using said
tag).

ps, semi-related. I'd like (as it not strictly insist on that, but I find it a bit
too ugly to do) to not further extend the already misused /version call if possible.
I just find it unidiomatic and adding a new one now with the current extra info would
be possible, we then could remove that extra info from /version with the next major
release.