rule Command

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

• NAME is the name you assign to the rule. Rule names must be unique. For more information, see About Administrative Object Names.
• CLAUSEs provide additional information about the rule.

Syntax

add rule NAME [ADD_ITEM {ADD_ITEM}];

• ADD_ITEM defines information about the rule including the description and access masks. The Add Rule clauses are:

  description VALUE

  [!|not]enforcereserveaccess

  icon FILENAME

  [!|not] hidden

  property NAME [to ADMINTYPE NAME] [value STRING]

  history STRING

  ACCESS_USER ACCESS_ITEM {,ACCESS_ITEM} [{USER_ITEM}]

  [!|not] splitchangetypeinterfaceaccess

  • ACCESS_USER is:

    | [revoke] [login] public [key STRING] |

    | [revoke] [login] owner [key STRING] |

    | [revoke] [login] user USER_NAME [key STRING] |

  • ACCESS_ITEM is:

    | all | | none | | [not]changevault | | [not]changename | | [not]changeowner | | [not]changepolicy | | [not]changesov | | [not]changetype | | [not]checkin | | [not]checkout | | [not]create | | [not]grant | | [not]delete | | [not]demote | | [not]disable | | [not]enable | | [not]execute | | [not]freeze | | [not]fromconnect | | [not]ignore | | [not]fromdisconnect | | [not]lock | | [not]majorrevise | | [not]modify | | [not]modifyform | | [not]override | | [not]promote | | [not]read | | [not]reject | | [not]reserve | | [not]unreserve | | [not]revoke | | [not]revise | | [not]schedule | | [not]show | | [not]thaw | | [not]toconnect | | [not]todisconnect | | [not]ubnlock | | [not]viewform | | [not]addinterface | | [not]removeinterface|

  • USER_ITEM is:

    [any | single | ancestor | descendant] organization

    [any | single | ancestor | descendant] project

    [any | context] owner

    [any | no | context | inclusive] reserve

    [any | no | public | protected | private |notprivate|ppp] maturity

    [filter | localfilter] EXPR

Some of the clauses are required and some are optional.

Assigning Access

Each access form is used to control some aspect of a business object’s use. With each access, other than all and none, you can either grant the access or explicitly deny the access. You deny an access by entering not (or !) in front of the access in the command. For every administrative object (attribute, form, program, relationship) governed by a rule, a user has access only if the rule specifically grants the user access. If the user isn’t granted access by the rule, the user won’t have access, even if the policy grants access to the user.

For example, suppose you don’t want anyone to modify an attribute called Priority unless they belong to the Management role. However, everyone should be able to view the attribute’s values. (Assume the person and policy definitions grant the appropriate accesses.) You would create a rule that governs the Priority attribute and define the following accesses:

Owner: read

Public: read

Management role: all

For more information, see Access Privilege Definitions.

While the complete list of access items is available when creating rules, when they are actually used, only the applicable privileges are checked. The table below shows the accesses each administrative type uses:

Use the following syntax to define access rules:

ACCESS_USER ACCESS_ITEM {,ACCESS_ITEM} [{USER_ITEM}]

• ACCESS_USER is:

  | [revoke] [login] public [key STRING] | | [revoke] [login] owner [key STRING] | | [revoke] [login] user USER_NAME [key STRING] |

  • Use the public, owner, and user keywords to specify that this rule applies to everyone (public), the object owner (owner), or to a named role (user USERNAME).
  • With revoke, all accesses specified as ACCESS_ITEMs are rescinded. If all conditions are true, then accesses are rescinded for the current user. Revoke supersedes all other rules. If a rule revokes access for a user, no other rule can grant access to that user.
  • Login specifies that the rule only applies if the role it specifies matches a role associated with the user’s current login context. This is more restrictive than the default, where the system looks at all user assignments to see if a rule applies to any of them.
  • The key STRING is a label that differentiates multiple rules defined for the same user. For example, if you have two rules defined for public or for user Designer, you can use the key STRING to need to differentiate them.
• ACCESS_ITEM specifies the kinds of access this rule governs, either granting or revoking access. For more information, see Access Privilege Definitions. With each ACCESS_ITEM, other than all and none, you can either grant the access or explicitly deny the access. You deny an access by entering not (or !) in front of the ACCESS_ITEM in the command. For example, !todisconnect or notchangeowner.
• USER_ITEM is:

  [any | single | ancestor | descendant] organization

  [any | single | ancestor | descendant] project

  [any | context] owner

  [any | no | context | inclusive] reserve

  [any | no | public | protected | private |notprivate|ppp] maturity

  [filter | localfilter] EXPR

  USER_ITEM specifies a variety of ways to define matching options between the current context’s membership in various organization and policy against the project or organization ownership of the object being checked.

  Flag	Description
  any|single|ancestor|descendant]organization	Specifies that the object’s organization owner must be checked against the context’s member organization.
  any|single|ancestor|descendant] project	Specifies that the object’s organization owner must be checked against the context’s member project.
  any owner	No check is performed on owner (default).
  context owner	Checks that object is owned by context user.
  any reserve	No check is performed on whether the object is reserved (default).
  no reserve	Checks that the object is not reserved by anyone.
  context reserve	Checks that the object is reserved by the current context user.
  inclusive reserve	Checks that the object is either reserved by the current context user or by no one.
  any maturity	No check is performed on the maturity of the project owning the object (default).
  public maturity	Checks that maturity on collaborative space of the credentials is public.
  protected maturity	Checks that maturity on collaborative space of the credentials is protected.
  private maturity	Checks that maturity on collaborative space of the credentials is private.
  notprivate maturity	Checks that maturity on collaborative space of the credentials is either protected or public.
  ppp maturity	Checks that maturity on collaborative space of the credentials is either private, protected, or public.
  [filter | localfilter] EXPR	A filter expression defined for the user access. Use localfilter instead of filter in policies and access rules to return only results to which the current user definitely has access. When you use localfilter, the expression is not evaluated by full-text search. Expression access filters can be any expression that is valid in the system. Expressions are supported in various modules of the system, for example, query where clauses, expand, filters defined on workspace objects such as cues, tips and filters, and so on. For more information, see Expression Access Filters.

Splitchangetypeinterfaceaccess Clause

The value of this clause determines which of these methods is used for adding and removing interfaces:

• If set to true, the addinterface and removeinterface accesses control access for interfaces.
• If set to false, the changetype access controls access for interfaces.

For example, a user wants to add an interface to an object and access is controlled by a rule. The system checks the value of the splitchangetypeinterfaceaccess clause to determine if the user has the required access:

• If splitchangetypeinterfaceaccess is true, the system checks the value of the addinterface access control.
• If splitchangetypeinterfaceaccess is false, the system checks the value of the changetype access control.

For more information, see Splitchangetypeinterfaceaccess Clause.

History Clause

The history keyword adds a history record marked “custom” to the rule 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.

Syntax

copy rule SRC_NAME DST_NAME [MOD_ITEM] {MOD_ITEM};

• SRC_NAME is the name of the rule definition (source) to be copied.
• DST_NAME is the name of the new definition (destination).
• MOD_ITEM s are modifications that you can make to the new definition. For more information, see Modify Rule.

History Clause

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

modify rule NAME [MOD_ITEM {MOD_ITEM}];

• NAME is the name of the rule to modify.
• MOD_ITEM is the type of modification to make. You only need to specify fields to be modified.

  Modify Rule Clause	Specifies
  name NAME	The current name is changed to the new name.
  description VALUE	The current description, if any, is changed to the value entered.
  enforcereserveaccess	The governed object must be reserved before a user can modify the object.
  notenforcereserveaccess	The governed object does not need to be reserved before a use can modify the object, however, multiple users could attempt to modify the object at the same time.
  icon FILENAME	The image is changed to the new image in the field specified.
  hidden	The hidden option is changed to specify that the object is hidden.
  nothidden	The hidden option is changed to specify that the object is not hidden.
  add owner ACCESS {,ACCESS}	The specified owner access is added. For more information, see Access Privilege Definitions.
  remove owner ACCESS {,ACCESS}	The specified owner access is removed. For more information, see Access Privilege Definitions.
  add public ACCESS {,ACCESS}	The specified public access is added. For more information, see Access Privilege Definitions.
  remove public ACCESS {,ACCESS}	The specified public access is removed. For more information, see Access Privilege Definitions.
  add user USER_NAME ACCESS {,ACCESS} [filter EXPRESSION]	The specified user access is added. USER_NAME defines the person, group, role or association for which the rule is being modified. For more information, see Access Privilege Definitions.
  remove user USER_NAME ACCESS {,ACCESS} [filter EXPRESSION]	The specified user access is removed. USER_NAME defines the person, group, role or association for which the rule is being modified. For more information, see Access Privilege Definitions.
  property NAME [to ADMINTYPE NAME] [value STRING]	The named property is modified.
  add property NAME [to ADMINTYPE NAME] [value STRING]	The named property is added.
  remove property NAME [to ADMINTYPE NAME] [value STRING]	The named property is removed.
  splitchangetypeinterfaceaccess	Use the addinterface and removeinterface access controls to determine if a user has the ability to add or remove an interface. For more information, see Splitchangetypeinterfaceaccess Clause.
  not splitchangetypeinterfaceaccess	Use the changetype access control to determine if a user has the ability to add or remove an interface.
  history STRING	Adds a history record marked "custom" to the rule 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.

Each Attribute, Form, Program, and Relationship definition can refer to one Rule that encompasses owner, public and as many different users as required. The Rule becomes part of the definition of these kinds of objects.

Attributes, Forms, Programs, and Relationships created before version 6.0 have no Rules defined. By default, all existing definitions will still have no Rules, and will remain available to all users as before. However, use the procedures below if you want to add a Rule to an existing definition.

To add a rule:

modify attribute ATTRIBUTENAME add rule RULE_NAME;

modify form FORMNAME add rule RULE_NAME;

modify program PROGNAME add rule RULE_NAME;

modify relationship RELNAME add rule RULE_NAME;

You can use the print rule command to list all policies that import the rule. To do so, use this syntax:

print rule RULENAME select | policy[]         |
                           | policy[].state[] |

delete rule RULE_NAME;

• RULE_NAME is the name of the rule to be deleted. If the name is not found, an error message will result.

When this command is processed, 3DSpace searches the list of rules. If the name is found, that rule is deleted IF there are no objects that are governed by the rule. If there are objects that are governed by the rule, they must be reassigned to another rule or the object must be deleted before the rule can be removed from the rule list.

To remove a rule from a specific administrative object, use the Remove Rule command on the object’s modify command. For example, to remove a rule from an Attribute, use the modify attribute command:

modify attribute ATTRIBUTENAME remove rule RULE_NAME;

Rules can be removed from attributes, forms, policies, relationships, and programs. For more information, see Assign Rule.