Search the Community

Showing results for tags 'roles'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • LogicModule Exchange
    • LM Exchange
    • LM Staff Contributions
  • Product Announcements
    • LogicMonitor Notices
  • LogicMonitor Product Q&A
    • Feature Requests
    • Ask the Community
    • From the Front

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 9 results

  1. Please add option to hide the Disabled Datasources object in the Resources tree from users who do not have Manage or higher privileges.
  2. 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.
  3. Currently, users need Manage rights to access the Config view. We need our junior sys admins to be able to view configurations without having the Manage rights. Please add a View only right for Config. The View Config right should only allow viewing of already collected configurations, but not permit Collect Now.
  4. We would like to see more of hierarchal relationship for user and role set up. We are an MSP with several hundred customers. Each one of these customers have about 5 to 20 logins. Right now the user set up is just one long list of every different customer user login. We would like to be able to create a Customer/Company login group, which LM is currently referring to as a role, and then move to that group and create the users and their permissions. This would make it much easier to manage. This same thing could apply to companies that us LM directly. They could group Departments in this same way. This is something that is pretty critical need for us. We're in the development phase with LM right now.
  5. Jeffrey McGovern

    Create role for API only user

    Problem I have a datasource that collects information from the LogicMonitor API. In order for this to work correctly I need a valid user on the LM platform with a valid API token. I can see two potential paths forward. Case 1 - Use my existing account as the datasource author with my API token. This has a big downside that if I have to leave the company for any number of reasons and my account gets disabled this datasource will stop working and is customer facing. This is probably not so good. Case 2 - Create a 'service account' inside LogicMonitor that can have its' own API token and if any one human needs to leave the company there really is not a big problem. The issue with this is that this user has a username and a password that can grant it access to the UI under all the permissions granted by the role but this account should/will never be used within the UI. This also generates a potential security problem because the password will most likely never be rotated because as long as the API user and token work this is simply going to sit there. Request Be able to create a new user type of 'API only' which will never have access to the UI and therefore you should not have to set any of the UI specific information for the account. This would remove the need for any of this information under that account: First/Last name/Email/Password/Force password change/2-factor/Phone/SMS/SMS Email format
  6. It would be great to be able to build dashboards with widgets associated with devices that the users role doesn't have access to. We have several "teams" at our organization that support several applications that have dependencies on large storage filers. I would like the ability to add a NetApp Volume Usage graph to their dashboards for only the volumes they are interested in without having to give them view rights to the entire NetApp filer. I ran into this limitation today when building a dashboard for a group only to find they couldn't see the graphs because they didn't have view rights to the group that the NetApp filer resided in.
  7. Miguel DeCamps

    User Roles

    It would be great if I could create a user role that had power user capabilities but without the ability to escalate their own account to the administrator level. The role would need to have permissions to create new users.
  8. I would like the option to assign view/manage role access to dashboards that exist within a dashboard group. We use wall mounted displays that cycle dashboards in a group for various clients using the slideshow feature. These displays are used by our support team so that they can keep an eye on clients at a high-level. We also want to provide a key contact at some of these client companies with view access to their respective dashboards. I see two ways to accomplish this currently: 1. We can clone the dashboard within the client dashboard group, then assign our client contact view access to the cloned dashboard. This allows us to keep the functionality of the dashboard group for our support team, but requires several duplicate dashboards. 2. We can skip the dashboard group and assign access for our support team and client contacts on a per-dashboard basis. This omits duplicate dashboards, but requires additional management of role permissions when creating new dashboards. Adding the ability to assign role permissions to nested dashboards would allow for simple access management for the support team, providing access to all dashboards within the "Clients" group, while also allowing one-off access to individual dashboards for client contacts without having to manage multiple dashboards per client. A simple toggle arrow (as is used in the Devices tree) could be implemented as a UI element to add this basic access management.
  9. I would like to propose that there be an additional column added to both the Devices and Services user permission selection to allow a user role to manage Scheduled Downtime. Our organization would like to allow application owners to manage their own SDTs without giving said group management rights to those devices or services in the logic monitor console.