per-user visibility of Alarms

[bdefloo]

Hi,

Would it be possible to define a specific group of users that can view an alarm in the NetXMS console/web interface?
This would allow a single NetXMS server to be more easily used by multiple people, but with different interests on the same nodes.

Perhaps even some sort of security settings for alarms, so you can select who can view/acknowledge/resolve/terminate alarms coming from a specific event processing rule? These permissions could then be ANDed with the existing permission set for alarms at node level.

[SKYnv]

@bdefloo said in per-user visibility of Alarms:

Hi,

Would it be possible to define a specific group of users that can view an alarm in the NetXMS console/web interface?
This would allow a single NetXMS server to be more easily used by multiple people, but with different interests on the same nodes.

Perhaps even some sort of security settings for alarms, so you can select who can view/acknowledge/resolve/terminate alarms coming from a specific event processing rule? These permissions could then be ANDed with the existing permission set for alarms at node level.

create user group.
create user without any priveleges.
add user to group.
create container.
bind some objects in this container.
go to properties/acces for this container.
add group to acces list and set priveleges.
All user in group able to see only these nodes and their alarms.

[bdefloo]

As I said, different people, but on the same nodes.

[SKYnv]

@bdefloo said in per-user visibility of Alarms:

As I said, different people, but on the same nodes.

what's wrong? try it.

[bdefloo]

I did. What I want to achieve is that, on for example a SQL server, SQL admins can see alarms about the SQL server (Page life expectancy, etc) and system admins can monitor system related alarms (temperature, C drive free space, ...), without having the other one's alarms clouding the console.

[SKYnv]

@bdefloo said in per-user visibility of Alarms:

I did. What I want to achieve is that, on for example a SQL server, SQL admins can see alarms about the SQL server (Page life expectancy, etc) and system admins can monitor system related alarms (temperature, C drive free space, ...), without having the other one's alarms clouding the console.

you mean group for alarms.
example
1.database events;
2.service events
3.device events
and etc

[bdefloo]

If it were implemented like the security tabs on objects you could use groups for it, yes.

Keep in mind events and alarms are two seperate things though; events come from agents and DCI monitoring and don't really have any user interaction, alarms come from the event processing policy.
Although each alarm has an event at its root, a single event might have to create different alarms for different target groups (like when the server goes down, both SA's and DBA's have to get an alarm). Security settings at the event template level wouldn't be very suitable for this, I think.

[victor]

Hi!

I agree that alarm separation could be useful. I see that it can be done that way: introduce new entity - alarm category, and on alarm creation (in event processing policy) add the ability to set category for alarm. Then users will be able to filter/group alarms by categories, and access control can be enforced on category level (i.e. do not define access rights for each alarm, but for category).

Best regards,
Victor

[bdefloo]

Sounds good!

I look forward to the next release(s)!