Forum Discussion

ncustis's avatar
ncustis
Icon for Neophyte rankNeophyte
9 months ago

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 ...
Dynamic group
permissions
  • Anonymous's avatar
    Anonymous
    9 months ago

    This seems like it would be a natural evolution of LM towards using actual multi-tenancy. The FR i submitted looks like this (in case you want to copy/paste).

    Inheritance of additional appliesto clause

    I would like to specify a property on a parent group called mandatoryAppliesTo and have that appliesto "AND"ed to every appliesto of every dynamic group under the group containing the property. 
    This would simplify our current appliesto and make our standard dynamic group definitions under each customer folder identical, with the parent folder adding to each dynamic group under the customer to ensure only that customer's devices are included.
    This also gives us the ability to delegate dynamic group management under customers to non administrators while ensuring they don't accidentally cross tenant boundaries.

    More details and discussion can be found here: https://community.logicmonitor.com/product-discussions-22/letting-non-admin-users-make-and-manage-their-own-dynamic-groups-4073?postid=14899

Anonymous's avatar
Anonymous
9 months ago

This isn’t that different to my recent post about (default) group ‘constraints’.

What I think would be a much better approach, and I can’t see that it would be hard for LM to implement in the back end is something like this...

  • create a new property name specifically for this, e.g. something like ‘mandatoryAppliesTo’. You would put this on a parent static group, anywhere in the hierarchy
  • when you create a dynamic group inside a static group that has that property, the dynamic group implicitly includes it in the AppliesTo logic, albeit not shown in the field (to then be removed by someone rogue)

In my scenario, mandatoryAppliesTo would be auto.organisation =~ “xyz” ( xyz here is customer acronym )
In ​​​@ncustis scenario, each SME team parent static group would have the ‘belongsToThisTeam’ logic required, and then those SME teams can create nested dynamic groups

This would be my preference.