Scenario:
The customer cloned the Symantec Administrator Role. When they cloned this role, they also checked the box for "Update targets".
This cloned security role still have at least Read access to almost everything as the previous Security Role.
When a User that belongs to this cloned Security Role goes to Manage>Computers and checks the available targets, they can see all the targets that the original Security Role had access to.
However, every target has a "lock" icon on them.
The customer made sure that this cloned Security Role is part of the "Scoping" for each of those desired targets. The process of cloning the security role when the "Update targets" option is selected, automatically added this cloned Security Role into the scoping.
If he tries to modify a target where they have scoping access, the options are grayed out.
When they want to assign a target to a policy, they can't. The option to move them appears grayed out.
If they clone any of those targets with a lock icon, they can add them to policies and edit them just fine.
Issue:
Any previously created Targets will not have the proper rights as this cloned Security Role should have since the original security role had access to them.
When logged in as a member of this cloned Security Role, every previously created target is "locked" for use, even when this cloned Security Role is part of Scoping.
Any new target created by a User on this cloned Security Role works for adding them to policies or editing.
ITMS 8.5, 8.6
This behavior is by design. Here is why (the case, when User has partial target scope, i.e. he now belongs to only 1 role out of the 2 roles, that target have scoped to):
Targets only can be modified by users that have full scoping coverage, i.e. users should belong to ALL scopes that target have.