Skip to main content
S
ssaul15-Moonstone
15-Moonstone
May 23, 2014
Solved

Source: disable access to subproject for all except special group

  • May 23, 2014
  • 3 replies
  • 2353 views

Hello,

we would like to disable access (openproject, fetchrevision) to a subproject for all except a special group.

Example:

project_A

|- (sub)project_B

|- (sub)project_C

group_A and group_B have access to project_A and project_C.

Only group_B should have access to project_B.

Our first approach was to allow the permissions for project_A for both groups and simply deny the permissions for group_A in project_B.

The problem is that some users may be members of both groups and so the deny overrides the permission.

We thought this might be a common configuration management task and so this should be possible, so maybe we overlooked something?

Is there another solution?

    Best answer by mrump

    Hi Stephan,

    at least for workaround you can allow the Access to Project_B explicitly for named users that are also members of group_A.

    User principal ACL entries overrule the group principal entries, so you can explicitly grand access to a user although one of his groups is denied.

    This worked fine for us during the last years, but it also means extra maintenance effort.

    HTH:

    Matthias

    3 replies

    K
    KaelLizak16-Pearl
    16-Pearl
    May 27, 2014

    Hi Stephan,

    Essentially, this comes down to creating a group of all of the members of A who are not also members of B, and then denying that group permission. Based on your problem, I'm going to guess you are using Integrity 10.3 or later.

    You might be interested in RFC 135701 (a feature request). In a nut shell, this feature request asks for the possibility to break the ACL inheritence chain on a project configuration, so that you could define permissions at that level "from scratch" at a given project/subproject level. Please contact Integrity Support to discuss this, and see whether it would be appropriate for your needs.

    Regards,

    Kael

    S
    ssaul15-MoonstoneAuthor
    15-Moonstone
    May 28, 2014

    Hi Kael,

    thanks for your hints.

    Yes, we are using Integrity 10.4.

    Creating a group of all of the members of A who are not also members of B won't work really good if group_A is the everyone group. Even if not, we would always have to change the new group and group_A simultaneously.

    The RFC sounds interesting - we asked support to be added to it.

    Stephan

    M
    mrump16-PearlAnswer
    16-Pearl
    May 28, 2014

    Hi Stephan,

    at least for workaround you can allow the Access to Project_B explicitly for named users that are also members of group_A.

    User principal ACL entries overrule the group principal entries, so you can explicitly grand access to a user although one of his groups is denied.

    This worked fine for us during the last years, but it also means extra maintenance effort.

    HTH:

    Matthias

    S
    ssaul15-MoonstoneAuthor
    15-Moonstone
    May 30, 2014

    While waiting for the (not very probable) implementation of the RFC, this seems to be the only working solution.

    Thanks, Matthias!

    K
    KaelLizak16-Pearl
    16-Pearl
    June 2, 2014

    Matthias' suggestion works best, if you have a small number of users who need access to Project_B. I've heard of two scripted approaches to this sort of issue: One is scripted group management, including a GUI built by one customer (not, to my knowledge involved with PTC Global Services), and the other involves what David Hegland suggests below to do this at a user level.

    Any of these three methods works better than waiting for that RFC to be implemented, but I would still recommend posting your organization against the RFC, since indications of customer demand do have some influence on which features are implemented.

    Regards,
    Kael

    D
    dhegland1-Visitor
    1-Visitor
    May 28, 2014

    Hi there. I like Matthias' suggestion. I've been using that approach for a couple years. To make it feasible I created a little script to spawn the personal ACLs from a group ACL. Here ya go.

    param(
    # --------------------------------------------
    # create-personalacls
    #
    # This script is for use by PTC Integrity Admins.
    # It is intended to work around group overlap when denies trump grants.
    # Personal grants will trump group denies, which is why this script exists,
    # to make it easier to manage personal ACLs without tedious manual effort.
    #
    # The script will create a personal ACL for each member of a given group.
    # You must first create an ACL for the group, and this script will
    # copy the permissions from that ACL into each user's personal ACL.
    # --------------------------------------------
    [String]$acl,
    [String]$group
    )
    $acloption='--acl='+$acl
    $users=aa.exe groups --members $group | select -skip 1 | foreach {$_.trim().split()[2]}
    $permissions=aa.exe viewacl $acloption | findstr $group | foreach {$_.trim().split()[0]}

    $users | foreach {
    $u=$_
    $permissions | foreach {
    $entry='u='+$u+':'+$_
    aa.exe addaclentry $acloption $entry
    }
    }

      Terms & ConditionsCookie settingsAccessibility statement