Letting non-admin users make and manage their own dynamic groups
We’ve got an environment that is maturing into a space where our SMEs are now wanting to take some ownership of their device organization and alert tuning. Part of that has butted up against dynamic group membership, but unfortunately (understandably), that can only be done by people who can manageallgroups, since obviously you could just make a dynamic group under a group to which you have access whose AppliesTo is just “true()” and thus gain access to every device in the org. We have been considering ways to facilitate access to these SMEs so that they can manage their own device groups, without giving them too much power with which they could accidentally delete or silence a bunch of devices they don’t own by a mistake in their AppliesTo logic. We’d really prefer not to just give these SMEs blanket Manage access, but we’d also like to avoid having a paradigm where they have to come to us to have every single dynamic group created for them. We’ve been considering Terraform, granting each team access to their own static group and letting them make subgroups inside of it,and adding what is effectively an AppliesTo prepend that is “belongsToThisTeam() &&” + “whatever their AppliesTo is.” This, unfortunately, would require them to know about and remember to use whatever custom module we’d build to add that prepend. Furthermore the way parent groups are set up, we’d have little to no way to restrict them to putting their new groups under the ones to which they rightfully have access. Has anyone else come up on these hurdles and figured out a way, or done some thinking on how to facilitate dynamic group management for specific teams without giving them the keys to the kingdom?Solved146Views13likes8Comments
More granular permissions for SDT actions
Please implement more granular permissions for SDT function. We would like to be able to grant permission to apply SDT to data sources elements, but NOT on the resource itself. We often encounter situations where by accident or carelessness our staff apply SDT to a resource instead of the data source element.0Views0likes0Comments
Permissions for Datasource, Alert, and Escalation Chain Groups
As we move towards a DevOps model, we increasingly have a need for small teams to have full admin access to the tools they use to manage their IT services. When it comes to LogicMonitor, this has proven difficult with the existing role permission model. DevOps pods would like to be able to manage their own datasources, alerts, and escalation chains but this isn't possible unless we give them broad access rights to those areas, which could cause significant harm to other groups of monitoring users. For example, an inexperienced DevOps user could inadvertently modify a datasource that applies to all Windows devices or they could create an alert rule that causes alerts not to be delivered to other users. To solve this problem, I'd propose that LogicMonitor offer alert groups, escalation chain groups, along with the existing datasource groups. Then, LogicMonitor could provide the ability to restrict roles to manage these specific groups. DevOps pods could be given the ability to manage their own custom subset of datasources and set up their own alerts in a rule range after the main set of rules.5Views4likes1CommentExpand role view permissions to include SDT
I would like to propose that there be an additionalcolumn added to both theDevices and Servicesuser permission selectionto allow a user role to manage Scheduled Downtime. Our organization would like to allow application ownersto manage their own SDTs without giving saidgroup management rights to those devices or services inthe logic monitor console.4Views1like1Comment