Managing Alert visibility on a "per-group" level
Good Morning all, we are a multi-Team managed service providerwho, surprisingly, manages customers team-wise. We are in the process of switching to LogicMonitor right now and we have some issues regarding shared devices and theirDataSource Instances, that belongs to different teams. We created Devicegroups for our teams, but if we put shared devices like loadbalancer, firewalls, storages etc. in said groups, ALL teams will see ALL alarms, regardless of responsibility. If one team decides to turn off an alarm on a shared device, the alarm is obviously deactivated on all other teams, as well. I'm aware of the Datasourceinstance grouping mechanism, but afaik it cant help with the problems i mentioned. We would like to request a feature where you can somehow mask datasources,their instances and their respective alarms based on the group you are in while you're viewing the device, so alarms andinstances that don't belong to your team doesn't show up at all. It would be really convenient to somehow configure a "view" of a device based on the group you are in that doesn't interfere with the devicedatasources. Bonuspoints if you bring in alarm-tuning in this somehow. :)/emoticons/smile@2x.png 2x" title=":)" width="20"> Regards, Bastian5Views1like3CommentsProvide a method for assigning group visibility independent of user roles.
We want to be able to show our clients their device groups in LM, butthat currently requires making a new role for every client user due to group visibility only being able to be modified on the role rather than onthe user directly. If we could assign visibility directly to users, that would allow us to control all non-group viewingpermissions for clients from a single unified role due to them having otherwise identical perms. There may be other ways to implement a solution to address this such as group inheritance, but the only option that currently existsis to manage hundreds of nearly identicalroles, each one attached to a single client user. Any general updates to customer permissions (stuff that isn't related to device viewing permissions)right nowrequires changing permissions in those hundreds ofroles to match each other rather than adjusting a single permission on a single role.1View1like6Comments
option to require FQDN
As we have run into numerous cases now where the device name uniqueness requirement has bitten us, my recommendation to LM is now this: * add a portal option to require a FQDN for all devices -- failure to include would cause rejection * add an option to have a default FQDN suffix defined as a group property which would be used when adding a new device within that group I am not sure what to suggest for Websites and the new Services naming, but similar issues apply, especially for the current RBAC-based MSP model.0Views0likes0Comments