group Command

[add|copy|modify|delete|list|print] group NAME {CLAUSE};

• NAME is the name you assign to the group. This name must be unique and cannot be shared with any other type of user (groups, roles, persons, associations). Assign a name that has meaning to both you and users. For more information, see About Administrative Object Names.
• CLAUSEs provide additional information about the attribute.

Syntax

Groups are created and defined with this command:

add group NAME [ADD_ITEM {ADD_ITEM}];

• ADD_ITEM is a clause that provides more information about the group you are creating. While none of the clauses are required to create the group, they are used to assign specific users and roles to the group. The ADD_ITEM clauses are:

  assign person PERSON_NAME [group GROUP_NAME]

  child GROUP_NAME {,GROUP_NAME}

  description VALUE

  icon FILENAME

  parent GROUP_NAME

  site SITE_NAME

  [!|not] hidden

  property NAME [to ADMINTYPE NAME] [value STRING]

  history STRING

If you are creating a group that is used in an app you must register the group as described in the Collaboration and Approvals Administration Guide.

Parent and Child Clauses

These clauses define the relationship of the new group to other defined groups. This hierarchy allows one group to share access privileges with another, saving time when defining access privileges when a policy is defined. You can have any number of child groups and any number of parent groups.

For example:

add group “Technical Marketing” parent Marketing;

add group “Quality Engineering Managers” parent Engineering,Management;

Of course, the group named as the parent or child must be previously defined. For more information, see Collaboration and Approvals Administration Guide: User Categories.

Assign Clause

The Assign Person clause assigns specific users to the group. A group can have no users, or they could have many. Groups with no users can be defined to show a hierarchical relationship between groups. In that case, the defined group acts as a parent for other groups.

Do not modify the persons creator or guest. Modifying these objects could cause triggers, programs or other application functions not to work.

assign person PERSON_NAME [group GROUP_NAME]

• PERSON_NAME is the previously defined name of a person.
• GROUP_NAME is the previously defined group.

If these names are not previously defined, an error message is displayed.

You can assign users groups in two ways, depending on how you are building your database:

• With the Assign Person clause in the add Group command, as described here.
• In the Person command. For more information, see Add Person.

Since previously defined names are required to make the Assign Person clause valid, it is not uncommon to wait before assigning persons to a group definition. When building the database, you might want to define only the groups and then handle the assignment of users in the person definitions. But, if you choose to define the persons first, or if you are adding a group to an existing database, you can assign users to the group with the assign person clause. Regardless of where you define it, an assignment made to a group becomes visible from all applicable definitions. This means that the link between the group and the person will appear when you later view either the group definition or the person definition.

When assigning a person to a group, you can also define that person’s role within the group. Again, once the assignment is made, it can be seen in all person, group, and role definitions when the definitions are viewed. Use the method and commands most convenient for your application and database.

Site Clause

A site is a set of locations. It is used in a distributed environment to indicate the file store locations that are closest to the group. The Site clause specifies a default site for the group you are defining. Consult your System Administrator for more information.

To write a Site clause, you use the name of an existing site. If you are unsure of the site name or want to see a listing of the available sites, use the list site command. This command produces a list of available sites from which you can select. For more information, see Locations and Sites.

Sites can be set on persons, groups, and roles, as well as on the Server (with MX_SITE_PREFERENCE). The system looks for and uses the settings in the following order:

• If using a Collaboration Server, the MX_SITE_PREFERENCE is used.
• If not using a Collaboration Server, or the MX_SITE_PREFERENCE is not set on the server, if there is a site associated with the person directly, it is used.
• If no site is found on the person, it looks at all groups to which the user belongs. If any of those groups have a site associated with it, the first one found is used.
• If no sites are found on the person or their groups, it looks at all roles the person is assigned. If any of those roles have a site associated with it, the first one found is used.

Add the MX_SITE_PREFERENCE variable to the 3DSpace Service initialization file (enovia.ini). This adjustment overrides the setting in the person, group, or role definition for the site preference, and should be set to the site that is local to the server. This ensures optimum performance of file chicken and checkout for Web clients.

Ancestor Selectable on Group

The select keyword “ancestor” returns the entire upward hierarchy of parents, as well as the user against which it is executed. For example:

project.ancestor match context.user.assignment.parent

This evaluates to true for data allowed for a user’s project.

History Clause

The history keyword adds a history record marked “custom” to the group that is being added. The STRING argument is a free-text string that allows you to enter some information describing the nature of the addition. For more information, see Adding History to Administrative Objects.

copy group SRC_NAME DST_NAME [MOD_ITEM {MOD_ITEM}];

• SRC_NAME is the name of the group that you want to copy.
• DST_NAME is the name of the new group.
• MOD_ITEM is the list of clauses that define the changes to make to the new copy. For more information, see the clauses listed in the next section.

Syntax

modify group NAME [MOD_ITEM {MOD_ITEM}]

After you establish a group definition, you can add or remove defining values. When modifying a group, it is important to consider how accesses are shared between parent and children. If you do not want a child to assume the same accesses to business objects as the parent, you will have to modify the policy so the privileges for the child group are specified. If a group is not specifically referenced in a policy, 3DSpace looks for access hierarchically. For example, if the group has a parent and the parent is named in the policy, the child shares the parent’s privileges.

The MOD_ITEM clauses for a group are:

[add] assign person PERSON_NAME [role ROLE_NAME] (for a group)

name NEW_NAME

description VALUE

parent GROUP_NAME

child GROUP_NAME {,GROUP_NAME}

remove assign | person PERSON_NAME [role ROLE_NAME] |              
              | all                                 |

remove child  | GROUP_NAME {,GROUP_NAME} |
              | all                      |

remove parent

site SITE_NAME

[!|not] hidden

add property NAME [to ADMIN] [value STRING]

remove property NAME [to ADMIN]

property NAME [to ADMIN] [value STRING]

If you remove a parent or child, you might inadvertently remove access privileges from the children. Make sure that you consult the policies you have created when you alter the hierarchy of defined groups.

History Clause

The history keyword adds a history record marked “custom” to the group that is being modified. The STRING argument is a free-text string that allows you to enter some information describing the nature of the modification. For more information, see Adding History to Administrative Objects.

When deleting a group, the elimination of linkages can affect another group’s access to business objects. For example, suppose you have these two groups: Assembly Team and Design Team. Assembly Team is the parent of Design Team.

According to the policy governing the Assembly Team group, this group has read access to all business objects of type Assembly. Since a child group inherits the access abilities of its parent group (unless specified otherwise), the Design Team group also has read access.

If the Assembly Team group is deleted, the linkages disappear between Assembly Team and Design Team. Design Team becomes a stand-alone group and loses the read access inherited from the Assembly Team group. If this access was critical, you can modify the group definition for Design Team with read access.