Restricting access to Global Item Changes

[Guest]

Hello,

Currently I am using LDAP permissions on my environment and appear unable to secure some of the core Administration.

Under Manage Users & Tasks I have the default:

Administer, Coordinate Releases, Deploy to Environment, Manage Application, View Application with Domain Users set to restricted on all Tasks, yet a Domain User in the OU can log in and modify the Plans and Templates at a Global level. Short of hosting on IIS and restricting URL access, what is the best way to resolve this?

-KM

Product: BuildMaster
Version: 5.0.7

[Guest]

In this case, it sounds like you'll want to create a "Custom Task". Check out KB#1120: Permission Updates in BuildMaster 5.0 if you haven't already. Basically, we renamed "roles" to "tasks", so now you "create a custom task" instead of "creating a new role".

The Security and Privileges section of the docs details how to create these custom tasks.

[Guest]

Hello Alana,

I'm confused, I am using the tasks and have everyone but myself restricted, yet a Domain User can log in and modify the Plans. See screenshot below; I would assume that this would restrict everyone from activity but it does not appear to be the case.

Also; I see that the conversion Plans_ManageGlobalPlans and Plans_ManagePlans and Plans_ViewActionDetails are all now part of Plans_Manage which removes some (possibly needed) granularity.

Kind Regards,
Kevin

[Guest]

In this case, I would basically change your configuration to:

Administer       |system   | [kemorgan]
View Application | system  | {Domain Users}

The restriction is really intended to override a permission already granted.

From there, you can add scoped permissions. And for example, developers access to do certain things in certain environments.

The reason that we combined Plans_ManageGlobalPlans and Plans_ManagePlans is because it having both was duplicative of application/environment scoped poermissions. Basically, If you don't want someone modifying global plans, then don't grant permission to "system" scope.

Is that helpful?

[Guest]

Hello Alana,

While the data is helpful, it does not match up to what can be done with the system. That is why I have all of the restrictions in place as I was testing. I've removed all restrictions and now only have KEMORGAN as Administrator with nothing else configured.

It appears that there is no correlating entity that relates to actual Template items themselves.

A domain user is able to log into the system and modify/save/delete Template items; they cannot modify the Plans themselves, but since Templates are under the same category they should be afforded the same permission.

See screenshots below as (1) Security Defined (2) NJOLLY logging in, no apps (3) NJOLLY viewing Template and modifying (4) NJOLLY success saved modified templated.

[Guest]

Ah ha, ok got it!

I've identified the bug, and we will fix this in [BM-2003], shipping ASAP!