Using Permission Groups with Civil - Intergraph Smart 3D - Help

Intergraph Smart 3D Civil

Language
English
Product
Intergraph Smart 3D
Subproduct
Civil
Search by Category
Help
Smart 3D Version
12.1 (2019)

The active permission group determines which objects you can modify. When you make changes that require objects from other permission groups to update, the software generates To Do List messages to notify users in those permission groups of these modifications.

Placing a branch on a header that is in a different permission group

In this example, the header run is in Permission Group One. A user belonging to Permission Group Two joins a branch to that header.

  1. Smart 3D trims the branch and generates a To Do List record on the header run.

    The software does not create an opening in the header run at this point.

  2. A user belonging to Permission Group One updates the To Do List record.

    Smart 3D creates the opening in the header run.

Modifying a header and branch run from different permission groups

In this example, the header run is in Permission Group One. A user belonging to Permission Group Two joins a branch to that header.

  1. A user from Permission Group One modifies the header run.

    Smart 3D modifies the header run and creates a To Do List record on the branch run.

  2. A user belonging to Permission Group Two updates the To Do List record on the branch run.

    The software makes the changes to the branch run and generates a To Do List record on the header run.

  3. A user from Permission Group One updates the To Do List record on the header run.

    Smart 3D modifies the header run and updates the opening with the new branch run position.

Example Configuration A

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

The administrator could configure the permission groups as follows:

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

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

  • 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.

Create the run using the PG-System permission group. When John works on his branch run, he should use PG-John as the active permission group. When Peter works on his branch run, he should use PG-Peter as the active permission group.

Example Configuration B

In this example, John and Peter, are working on different runs.

The administrator could 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 and routes an initial header run using PG-John as the active permission group. Peter then needs to route a branch from John's run.

  1. Peter sets PG-Peter as the active permission group and selects the header in John's run from which to branch.

    The software creates the branch run and generates a To Do List item for John.

  2. John updates the To Do List item.

    The software modifies the header to have an opening at the branch routed by Peter.