Open for Voting

Granular Node Management Rights.

There needs to be a simple way to assign users specific node management rights. For example, i have a group of users that i only want to be able to unmanage nodes, nothing more. There may be sophisticated ways of achieving this but it would be nice to have it built into the "Manage Accounts" section.

Thanks for considering this.

Parents
  • There are 27 upvotes for this topic and nothing from development indicating that it's being worked on.  In fact I see nothing on the feature requests section as being changed since 10.4.0 was released.  I do see a 10.4.1 available as a release candidate from the customer portal page, but the release notes only indicate that the update addresses specific bugs that have been submitted by customers.  Everything is listed by case number and has a relatively vague description of what it addresses.  Since the community does not have the ability to look at individual case numbers submitted, this is kind of useless to everyone as a whole.

    Being that these items such as Granular Node Management Rights is such a critical issue for many enterprise customers, I would hope that SolarWinds would be taking them more seriously or working on them more aggressively.  I have a hard time justifying over 20K a year in just renewal fees for a product that constantly seems like it's in beta testing.  We need these issues addressed...  As the NPM manager, I find it frustrating to come across something that I personally audited 6 months ago and find that someone has deleted the node or its contents.  I want to eliminate the ability for anyone NOT an ADMIN from deleting or unmanaging Nodes all together.  I want my customer support team to be able to use the searching features from the Node Management page and not have the ability to edit or delete any information at all.

    I think that the community has made it pretty clear that this item specifically NEEDS to be addressed sooner than later.  When is this item going to be flagged as "Being worked on" ???

  • Hi Brandon,

    10.4.1 is mainly service release fixing important issues and reported problems.

    Our Thwack community has brought a lot of reasonable and good requests which is very valuable and we really appreciate. We are trying to process/implement feature regarding their priority and problem they can solve. For example, we are currently working on routing functionality in NPM which is not in top list of feature here on thwack but it was requested from current and non NPM users as something that's very important for troubleshooting of network infrastructures. Another feature we are working on is completely new reporting with charts. This is also not "most wanted" but almost every single user of NPM know that current reporting is a bit outdated and needs for example charts or web-based console for definition.

    I'm not saying your request is not important to you, it is based on the use you wrote. We have just limited capacity on engineering side so it can really take some time to have it implemented.

  • Michael,

    This and a couple of other critical feature requests that have 100 more votes than this one are getting ignored for what, Network Atlas Enhancements, Further enhancements to charting or reporting, simply aren't as critical as these deal breakers to various high-volume or large scale use cases, like this, Syslog/Traps, or proper 2-d multi-column UnDP handling.

    Peter

Comment
  • Michael,

    This and a couple of other critical feature requests that have 100 more votes than this one are getting ignored for what, Network Atlas Enhancements, Further enhancements to charting or reporting, simply aren't as critical as these deal breakers to various high-volume or large scale use cases, like this, Syslog/Traps, or proper 2-d multi-column UnDP handling.

    Peter

Children
  • Agreed.  It seems like realistically without any sort of proper user handling tools and permissions granularity it is entirely possible to "outgrow" NPM.  People have made topics and requests specifically on node management granularity for three years now, but it never seems to make the cut in any capacity.  Without a more layered approach to authorization and permissions within NPM it becomes increasingly hard for us to justify the cost.  Even some of our most basic usage scenarios now revolve around the risk of giving users way more rights than they need versus the benefit of them being able to do a single, simple task (such as unmanaging a server before rebooting it, or modifying the custom properties of a node).