[pbs-devel] [PATCH many v4 00/43] integrate notification system

Lukas Wagner l.wagner at proxmox.com
Tue Apr 23 13:13:17 CEST 2024



On  2024-04-22 16:24, Fabian Grünbichler wrote:
>> Rough edges:
>>   - Datastore option view in UI could be improved. When 'notification-mode' is
>>     set to 'notification-system', we should indicate that 'mailto-user' and the
>>     other notification settings have no effect. Already did that in the edit
>>     window, but in the grid panel I did not find a quick way to do that.
> 
> in general this series looks mostly good to me, some rough edges I
> noticed while testing:
> 
> - if the user lacks Sys.Audit, the notifications part is empty, even
>   though there are built-in targets/matchers, this might cause
>   complications for one-off tasks that allow selecting notification
>   things, or cause confusion on the user's side

One-of tasks/jobs only allow selecting the notification mode, so whether
to use the old 'email to some user' style or the new notification system,
but not any details. So I think it should be fine? Unless I'm missing something.

It would of course be nice to fail a bit more gracefully when privs are missing,
e.g. hide the notifications panel completely if .Audit is missing, or disable
the 'modify' buttons if .Modify is missing... but I think this should be done later,
this potentially requires coordination with PVE.

> - the datastore/job related checks when configuring notifications
>   currently don't allow access to datastores with just Datastore.Backup,
>   and not .Audit, even though such datastores/jobs are fully accessible
>   by the user..

Fixed - the API handler which returns the list of known metadata values now
uses the /admin/datastore API instead of /config/datastore.
The first one requires Datastore.Backup/Datastore.Audit, while the latter
only returns datastores for which the users has at least Datastore.Audit.

> - docs/config/notifications/format.rst has partly invalid content

Fixed - copy/paste mistake :)

> - Sys.Modify is only contained in the Admin role atm, which has a lot of
>   other privs - maybe we want to have our own NotificationsAdmin? not
>   sure whether that makes sense.. maybe it would be better to think
>   about this for a bit and maybe add a priv if we want to make this
>   configurable by "medium privileged" users, since Sys.Modify is quite
>   the heavy hammer anyway..

Good point. I mean on PVE we use Mapping.* and therefore can use
the PVEMapping* roles to to administer notifications, which is 
more of a 'medium sized hammer' ;) . On PBS I did not
find anything more fitting than Sys.*, so maybe it would make sense to
introduce something new, either only a new role or also new privs.

Not sure if we have to do this now or can do this at a later point?
Any way, I'm open for suggestions. :)


-- 
- Lukas




More information about the pbs-devel mailing list