Learn about permission groups and routing - Intergraph Smart 3D - Administration & Configuration

Intergraph Smart 3D Project Management

Language
English
Product
Intergraph Smart 3D
Subproduct
Project Management
Search by Category
Administration & Configuration
Smart 3D Version
12.1 (2019)

Several different users in different permission groups can work together when routing if you know how the software handles the different situations. Piping fully supports different users who have different sets of privileges and work on different runs, such as when working in a Global Workshare Configuration.

The software creates an Intermediate End Feature (IEF) at the end of a pipe run connected to another pipe run and creates a logical connection between the two IEFs/runs. The legs stop at the IEF and are not shared between pipe runs. You do not need to create a separate permission group for the pipe run or the pipe run features. All piping objects can be in the same permission group.

Assignment of Permission Groups

Permission groups are assigned as follows:

  • Objects that you create directly are assigned to the active permission group.

  • Objects the software creates are automatically assigned a permission group determined by an internal set of rules. The permission group assigned is not necessarily the active permission group. Examples of automatically placed objects include connections and a pipe automatically inserted when two touching valves are separated.

  • Parts generated by features are assigned the permission group of the parent feature; however, runs can be in a different permission group than their collective features and parts.

  • End features use the permission group of the run to which they belong.

  • Connections use the permission group of the parts to which they are connected. If the connection is between parts with different permission groups, the permission group to which you have write access is used. If the connection is between an equipment nozzle and a route part, the route part permission group is used for the connection.

  • Piping connection objects (such as welds, bolt sets, gaskets, and clamps) use the permission group of the connection that generated the object.

Systems and Permission Groups

A system is a logical grouping of sub-systems. When you add or remove a sub-system, you also modify the parent system definition. Therefore, you must have write access to the parent system. You do not need write access to the grandparent system. For example, to create a pipe run, you need write access to the parent pipeline. However, you do not need access to the system to which the pipeline belongs.

When participating in a Global Workshare Configuration, you must manage all permission groups at the host site. The sub-system requirement for write access to the parent system is not possible if the sub-system's permission group is created at the satellite site and the parent system's permission group is created at the host site.

For example, your host site is Houston and your satellite site is London. You create a system called Pipe Rack 100 and its controlling permission group is in Houston. You assign write access to a user who works in London. During the workshare replication process, the Pipe Rack 100 system and permission group are duplicated in London. The user in London can add objects such as columns, beams, and braces to the Pipe Rack 100 system because you gave that user write access to the system's permission group in Houston. The London user cannot delete or change any of the properties of the Pipe Rack 100 system in London because the host site, Houston, owns it. He can only add objects to the system. If the London user travels to Houston and logs on there, that user can delete or change any of the properties of the Pipe Rack 100 system because the Houston host site owns it.

Example Configuration A

In this example, two users, John and Peter, are working on the same run with exclusive access. John is responsible for part of the run, and Peter is responsible for the other part of the run. Neither John nor Peter should be able to modify the work of the other person.

The administrator should configure the permission groups as follows:

  • Create three different permission groups: PG-Run, PG-John, and PG-Peter.

  • Both John and Peter should have full control access to PG-Run.

  • John should have full control access to PG-John while Peter should have read-only access to PG-John.

  • Peter should have full control access to PG-Peter while John should have read-only access to PG-Peter.

The run should be created using the PG-Run permission group. When John works on his parts of the run, he should use PG-John as the active permission group. When Peter works on his parts of the run, he should use PG-Peter as the active permission group. The two halves of the run should connect at a component such as a valve (piping) or a union (electrical).

For example, John routes his part of the run, places a flange, and then places a gate valve. Peter then places a flange manually connecting to the open port of the gate valve, and then continues his part of the run.

Example Configuration B

In this example, two users, John and Peter, are working on different but in-line connected runs with exclusive access. For example, John places an elbow, a straight piece, and a union, then stops. Peter connects to the open port of the union, and then continues routing. The administrator should configure the permission groups as follows:

  • Create two different permission groups: PG-John and PG-Peter.

  • John should have full control access to PG-John while Peter should have read-only access to PG-John.

  • Peter should have full control access to PG-Peter while John should have read-only access to PG-Peter.

John should create the run using the PG-John permission group and route his part of the run. When Peter works on his part of the run, he should use PG-Peter as the active permission group. The Intermediate End Features will handle the connection between the two parts of the run.

Example Configuration C

In this example, two users, John and Peter, are working on different runs connected by branching components such as a tee. The administrator should configure the permission groups as follows:

  • Create two permission groups: PG-John and PG-Peter.

  • John should have full control access to PG-John; Peter should have read-only access to PG-John.

  • Peter should have full control access to PG-Peter; John should have read-only access to PG-Peter.

John creates an initial header run using PG-John as the active permission group and routes it as needed. Peter now wants to branch from John's run. Peter sets PG-Peter as the active permission group and selects the header in John's run from which to branch. Instead of creating the header component (such as a tee), the software generates a To Do List item for John.

When John updates the out-of-date To Do List item, the software modifies the header to add the tee, and then generates a To Do List item for Peter.

When Peter updates his out-of-date To Do List item, the software fixes the branch leg (the end of the branch leg is adjusted to the tee port). This is called a double hand-shaking mechanism.

Example Configuration D

In this example, an administrator has created two separate Windows® Active Directory groups, each with different permissions, under the model.

  • The first Windows® Active Directory group, Group A, has been assigned write privileges to the permission group, PG-1. A user, John, is a member of this group.

  • The second Windows® Active Directory group, Group B, has been assigned read-only access privileges to PG-1. John is also a member of this group.

Because John is a member of Group A, which has write privileges, John therefore has write privileges to PG-1.