Locked
Discussion interactions are currently paused.
Provide a method for assigning group visibility independent of user roles.
We want to be able to show our clients their device groups in LM, but that 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 on the user directly. If we could assign visibility directly to users, that would allow us to control all non-group viewing permissions 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 exists is to manage hundreds of nearly identical roles, each one attached to a single client user. Any general updates to customer permissions (stuff that isn't related to device viewing permissions) right now requires changing permissions in those hundreds of roles to match each other rather than adjusting a single permission on a single role.
Mosh
·6 years agoI'd be interested in this discussion too.
Cole McDonald
·6 years agoI'm also happy to start another discussion thread and hold a public discussion on the topic so anyone with input could chime in if they were so disposed.
Paul_Armenakis1
·6 years agoHey Cole,
I work with David, We have been working on tackling the per-customer alert rules as well. If you're interested, we should talk via DM and exchange some ideas.
Cole McDonald
·6 years ago...either an alias to a master device in each of the groups... or a group membership field in the device detailing where it should show up. Every group then becomes dynamic... although, you could potentially do that now by adding a property token and using dynamic groups to gather based on those tokens. Everything parents to your infrastructure group, but then per customer tokens could populate dynamic customer groups. I'm doing that for a few of our customers. The dashboards I build are generic and use tokens in the device / group filters. They are then cloned into a customer group that sets the token telling it what devices to display. The users are set to those groups. that way the dashboarding is simple for them to access and for me to deploy. Semi-relatedly, I'm trying to figure out how to use that same mechanism to make a "slicer" widget that would allow me to have a check list of servers on a dashboard, then dynamically adjust which are being shown in other widgets on that dashboard at any given time.
I've also entered a request for sub-dashboards so you could have an NOC dashboard that allows a user to click through to a performance dashboard for that particular device... but not actually the device itself.
David
OP6 years agoBeing able to delineate dashboards that way would be great as well. The workaround system we have for alerts is that we have two root folders, one is Managed Service Infrastructure and one is Customer Infrastructure. Everything that exists in Customer Infrastructure also exists in Managed Services Infrastructure, though that is not always the case vice-versa. Each of our clients has a sub group in the customers folder containing their VMs, private cloud infrastructure, etc. When a new device is added, it's added both to the Managed Service Infrastructure group and the Customer Infrastructure group. We set all of the base thresholds against the Managed Services Infrastructure group and aim all of the customer-specific threshold adjustments against the Customer Infrastructure client sub groups.
Cole McDonald
·6 years agoWe're in the same situation. We provide managed cloud hosting and have dozens of clients who we are rolling into having customer specific dashboard implementations. Same bloat ends up happening with alerts as well. If a customer gets an alert, it interrupts the flow of the alerts to our normal yellow/orange/red defaults... so if we have to add a single customer specific alert rule, we have to add extras of that for every possible iteration of it in very specific orders with tons of filtering. It would be nice to have a passthrough / inheritance method on those as well for the same reasons as you're covering for the user permissions.