Workspaces and permissions

Helix IPLM allows users to load workspaces from IP Hierarchies for which they may be missing permissions to some resources. This concept is referred to as 'Partial Workspaces'. Partial workspaces allow the same IP Hierarchy to be leveraged for all team members, no matter whether they have permissions to all sub resources. Releases, Updates, and loads all function normally in a partial workspace.

Read permission on an IPV’s Line allows a user to load that IPV into the workspace. A user cannot load an IPV for which they only have view permission into a workspace.

IP and Line permissions for loading a workspace

To build a workspace, a user needs read permissions to at least the top level IPV in the IP Hierarchy. 

Given the following IPV Hierarchy: 

Permissions example 
> pi ip tree drinks.cosmo
drinks.cosmo@1.TRUNK
├─ drinks.cranberry_juice@1.TRUNK
├─ drinks.orange_schnapps@1.TRUNK
└─ drinks.vodka@1.line1
  
> pi ip load drinks.cosmo

In order to load the entire hierarchy into the workspace the user needs to have at least read permissions on the following lines:

Permissions Example 
drinks.cosmo@.TRUNK
drinks.cranberry_juice@.TRUNK
drinks.orange_schnapps@.TRUNK
drinks.vodka@.line1

This user doesn't need permissions on other lines of the IP (for example, drinks.vodka@.TRUNK) since they are not being populated in the workspace.

Partial workspaces 

Helix IPLM supports building workspaces by users that don't have read permissions on all the lines in the IP tree. This allows users to be given partial permissions and still work on the IP or project. Helix IPLM supports this, so there is no special configuration needed.

If a user attempts to load a workspace for which they don't have all the required permissions, Helix IPLM will load only those IPs for which the user has at least read permission on the line being loaded. Note that this means that any sub-IPs implied by an IP for which the user doesn't have permissions will also not be loaded, even if the user has read permissions on those sub-IPs.

For example, if the user tries to load the following IP 'lib.A' into a workspace:

Loading Lib.A 
lib.A@1.TRUNK
 ├─ lib.B@1.TRUNK
 └─ lib.C@1.TRUNK
    └─ lib.D@1.TRUNK

If a user lacks read permission on lib.C@.TRUNK but has read permission on the lines of all the other IPV (including lib.D@.TRUNK), then Helix IPLM will not load the IPV lib.C@1.TRUNK or lib.D@1.TRUNK into the workspace.

Conflict resolution in partial workspaces

IP tree conflicts are detected after the permission filtering, and conflict resolution (both --resolve and automatic resolution) is based on that partial tree. If the '--resolve' property refers to a resolution resource that user does not have access to, then that '--resolve' property will be ignored. 

For example, in the following IP tree:

IP Tree 
lib.A@1.TRUNK
├─ lib.B@1.TRUNK
└─ lib.C@1.TRUNK
    └─ lib.B@2.TRUNK

Assume that the user lacks read permission on lib.C@.TRUNK but has read permission on the lines of all the other IPV. Also, lib.A@1.TRUNK has --resolve lib.B@2.TRUNK, then the tree that is loaded into this user's workspace is:

IP Tree 2 
lib.A@1.TRUNK
├─ lib.B@1.TRUNK

Conflict resolution of B@2.TRUNK is ignored in this case since there is no conflict in the tree after permission filtering.

Releasing a partial workspace

Releases made in workspaces with partial resources due to permission will not affect hidden resources (IPVs that are not part of the workspace due to permissions). Hidden resources will be carried forward without any change. An info message will let user know release was made from partial workspace with hidden resources carried forward.

If user loses read permission on a resource before the release while the resource is in the workspace, then there will be a directory in the workspace for the IPV to which the user has lost read permission. Without read permission, the resource would be hidden and will be carried forward unmodified. The changes in the resource directory in the workspace will be ignored, since this directory will now be treated as 'unmanaged'.

If user gains read permission on a resource before the release while the resource is not in the workspace, then the directory in the workspace corresponding to the IPV to which user gains read permission will be missing. Therefore, the user will be required to run an update before attempting the release. The update will create the missing directory.

For both gain, or loss, of read permission to IPV which was/now is hidden, the following will succeed:

  • Release of IPV without any direct resource IPV which was, or now is, hidden. Any direct resources which were, and still are, hidden will simply carry forward.

The following will fail:

  • Releasing a hidden resource by running "pi release resource".
  • Releasing a hidden resource's sub-resource which can only be accessed through the hidden resource will fail, regardless of what permission user has on this sub resource. If the sub-resource is also hidden, the Error will indicate that the IPV does not exist in Helix IPLM. If user has read permission, the Error will indicate that the IPV is not a resource of the workspace.

Hierarchical release

If the user gains permission to a previously hidden resource, and one or more resources cannot be released because of this gain in permissions, then the release will fail. This is because hierarchical releases are atomic.

If a user loses permissions to an existing resource in the workspace, then the resource in question is hidden. Any directory with name of hidden resource is ignored, and hidden resource carries forward to new release. Hierarchical release will succeed.

Updating a partial workspace

Between the last update/load of the Workspace and the incoming update:

  • If the user does not have resource's read permission before the last update/load but gains read permission before the incoming update, the resource will be included in the resource tree from the server, which will be conflict resolved and used as the target version during the update.
    • Running "pi up IPV" on any IPV that contains a missing resource will bring this resource into the Workspace.
    • Directly running "pi up resource" for this missing resource when it's not in the Workspace will generate an error.
  • If the user has resource's Read perm before the last update/load but loses read permission before the incoming update, the resource will be hidden. Any directory in the workspace corresponding to an IPV to which user loses read permission will be treated as unmanaged.
    • Running "pi up IPV" on any IPV that contains this resource will remove the resource (and all IPV in the resource's hierarchy which can only be accessed through a hidden resource) from the Workspace.
    • Directly running "pi up resource" on this resource will generate an error.
    • If there are open files for this resource or any of its sub-IPs that are only accessible through this resource, pi up will try to remove as many files as possible of these resources.
    • If user tries to run pi up on the resource's sub resource which are only accessible through this resource, update will succeed. (This can only happen before this resource is removed from Workspace by an update).

When a user updates a Workspace and results into a partial Workspace due to permissions, a Info message will be generated to indicate the workspace is not complete. There will also be an Info message for dry-run.

Unix groups

The Unix group set on an IP when it is loaded in a workspace is configured via the '–unix_group' project property. This setting applies to both IPVs in local and refer mode in the workspace. See the Workspace Configuration page for details on setting project properties.

Note it is also possible to set ACLs (Access Control Lists) on IPVs loaded in refer mode in IPLM Cache. More details on this oar on the IP Caching page.