Use attributes
This section explains how to use object attributes in the Administration Console.
Attributes section
The Attributes section is available for relevant object types in Administration Console > Configuration Object Management > Object Type Definitions. For details, see Object Types content area.
You can perform the following tasks in the Attributes section:
-
List, define or update attributes for a particular object type for a particular product.
-
Assign and unassign the attributes for an object type.
-
Associate valid sets of values (single-column or multicolumn) for object attributes in the current product. Constraining certain attributes to valid sets is done for particular object types only.
-
Set default values, help text, valid set usage, and so on for attributes, and to arrange any of these values into multirow, multicolumn blocks.
Note: For individual objects, this function specifies the existence of particular user-defined attributes, but does not assign values to them (other than default values). You specify attribute values for a specific object using the Dimensions CM web client or desktop client.
-
Specify rules on updating attributes and role sections.
-
Copy existing rules and role sections from elsewhere.
The Tool Manager and Product Manager can update attributes for all object classes, while Change Managers can update request attributes, and Part Managers can update design part attributes.
User-defined attributes
A user-defined attribute is a custom attribute that you set up for an object type. You can define user-defined attributes in the Administration Console.
A user-defined attribute consists of global and local properties:
Global properties | These properties are independent of the assigned object type. Examples of global properties include the attribute name and maximum length. |
Local properties | These properties are related to the specific object type. Examples of local properties include the user prompt and default value. |
For each object class, you can define a number of user-defined attributes in a base database. For an Oracle or SQL Server database, this can be up to 996. For greater flexibility, Dimensions CM allows to reuse the same attribute with different local properties across object types. This enables you to derive more attributes from the maximum number allocated to each object class.
Typically, each attribute definition includes:
-
The name of the attribute.
-
The maximum length of the attribute value.
-
The user prompt displayed as the field label for the attribute.
-
The data type for the attribute value. For details, see Attribute types and data types.
-
The display length and height of the attribute.
-
An optional valid set of values.
-
Attribute update rules and role sections. For details, see Attribute update rules.
This example demonstrates how to use the same attribute for different objects.
Stephanie, the administrator, wants to define an attribute named NOTES for the RMR and CR request types. For the RMR type, she wants to define a user prompt called "Review Notes." For the CR type, she wants the user prompt "Inspection Notes."
Stephanie creates the NOTES attribute for the RMR type with the appropriate user prompt, and then assigns NOTES to the CR type and changes the user prompt. In this way, Stephanie can modify the same attribute for use with two object types without creating two separate attributes.
Attribute types and data types
The type of attribute determines if the user can enter a single attribute value, a row of values, or a table of values.
Type | Description |
---|---|
Single-field, single-value | One value for the attribute. |
Single-field, multivalue | Multiple rows of values can be assigned to the attribute. |
Multifield, multivalue | Multiple rows and columns can be assigned to the attribute. |
The data type determines what kind of information the user can enter as the attribute value. Below are the valid data types.
Data type | Description |
---|---|
Character | One or more lines of text. |
Date | The date in format DD-MMM-YYYY HH:SS. You can enter a date or select it in the calendar. |
Number | A real number or integer. |
Reserved system-defined attributes
Dimensions CM has a number of system-defined attributes for various object types. Do not create attributes that have the same names as reserved system-defined attributes.
The following table lists the reserved attribute names:
Item attributes | FORMAT, FILENAME, FILE_VERSION, ITEM_SPEC_UID, DIR_UID, LIB_FILENAME, LIB_CHECKSUM, LIB_FILE_LENGTH, CHECKSUM, FILE_LENGTH, EDITABLE, COMPRESSED, DIRPATH, USER_FILENAME, REVISED_DATE, SENDER_ID, SHARED_BRANCH, STAGE_ID, EXTERNAL, CREATE_DATE, ORIGINATOR, PHASE, LIFECYCLE |
Design part attributes | PARTNO, LOCALNO, PHASE, ORIGINATOR |
Request attributes | SENDER_ID, STAGE_ID, CHSEQ, CREATE_DATE, ORIGINATOR, NO_ACTIONS, SUPER_TYPE, PHASE, UPDATE_DATE, LIFECYCLE, DELEGATED_OWNER_SITE, REFERENCE_ONLY, OWNER_SITE, LOCKED |
User attributes | PRIVILEGE, EMAIL, BASEDB, SITE, DEPT, PHONE, FULL_USERNAME, GROUP |
Baseline attributes | SENDER_ID, STAGE_ID, BASELINE_METHOD, TEMPLATE, BASELINE_TYPE, CREATE_DATE, ORIGINATOR, PHASE |
Valid sets of values
A valid set is a discrete list of values that can be assigned to a particular attribute. A valid set provides the permitted values that you can select when specifying an attribute for an item, request, baseline, design part, or user.
Valid sets ensure that you only enter valid combinations of data into attributes.
A simple valid set contains a single column that lists the acceptable values for one attribute.
For example, a valid set for the attribute Urgency could contain values High, Medium, and Low. A more complicated valid set could consist of up to eight columns, which can limit the combinations of values for up to eight different attributes.
When the user completes a field belonging to the valid set, Dimensions CM restricts the permissible values for other valid set fields accordingly.
Stephanie, the administrator, creates a valid set called CUSTOMER_NAME that contains the following columns and rows:
CUST_SITE | CUST_NAME | CUST_CONTACT |
---|---|---|
Azur SA |
Marie Sancerre |
10 46 92 21 56 |
High Tech Inc |
Jane Doe |
810 544 6771 |
Technik AG |
Klaus Schmidt |
89 5904 7112 |
Widgets Ltd 2 |
Joe White |
01279 999001 |
Widgets Ltd 2 |
Fred Gray |
01279 999001 |
Stephanie then assigns the first column of the valid set to the attribute CUST_SITE, the second column to CUST_NAME, and the third to CUST_CONTACT.
Will, a developer, selects the Widgets Ltd 2 value for CUST_SITE, and then chooses between the CUST_NAME values, Joe White and Fred Gray. Sarah, another developer, selects High Tech Inc for CUST_SITE, and the values for the other attributes are filled in automatically.
Note: The order in which the fields are evaluated is determined by the DM_SMART_ATTR_VALIDATION symbol in the dm.cfg server configuration file. If this option is set, valid set fields are evaluated from left to right. Values to the left of a field are not restricted by what is entered, only values to the right. For details about the DM_SMART_ATTR_VALIDATION symbol, see Administration.
Attribute update rules
You can generally update attributes if they have the required update privilege. Also, update rules may specify whether a particular role can view and update a specific attribute and whether an attribute value is required.
Each rule can apply throughout the object's lifecycle or only when an object is in a particular lifecycle state.
Example: For requests of type Problem Report, you could specify that the SEVERITY attribute can be updated only by a user with the Reviewer role during the DEFINED state.
Update rule guidelines:
-
Attributes cannot be updated unless it is in the user's inbox.
-
If there are no rules for an attribute, the attribute is displayed in Dimensions CM as writable and not required.
-
If there are attribute rules defined for a particular state, then by default all attributes are not writable and not required at that state.
But if a rule exists for an attribute with the Writable at the From state setting enabled for a particular state, this rule takes precedence, and the attribute is writable.
-
If a rule is defined for an attribute as Required when actioned to the To state for a given From state and To state pair, the attribute is displayed as required in the Action dialog box when making the transition.
Note: The Attributes tab in the Edit Attributes dialog box displays required attributes based on the next lifecycle state (normal or off-normal).
-
Change Managers see all Dimensions CM requests as writable and not required, and Product Managers see all items and baselines as writable and not required.
Stephanie wants to create a rule so that a particular attribute is required during a transition between the Approved and Implemented states. She chooses the attribute name and role, and then sets the following:
-
From state: Approved
-
To state: Implemented
-
Display in this role section: Set
-
Writable at the From state: Set
-
Required when actioned to the To state: Set
As a result, a user with the specified role must define a value for the attribute in the Action dialog box when actioning the object to the Implemented state. The user could also define the value in the Edit dialog box before actioning.
Attribute role sections
In the attribute update rules, you can specify if you want an attribute to be displayed in a role section.
A role section is a list of attributes that are pertinent to the holders of a particular role in an object's lifecycle. When viewing and updating attributes, users can choose one of these sections in order to reduce the list to what they want to see.
For example, a user with the Developer role is normally interested in a certain subset of the user-defined attributes of an item revision, while a user with the Quality Assurance role is interested in a different subset.
Every attribute defined for an object type can be included in, or excluded from, any role section. Note that role sections simply classify attributes according to roles and do not specify permissions. Any authorized users are permitted to view any of the role sections, regardless of whether they hold the corresponding roles.
Stephanie wants to create a rule to set a role section for a particular attribute in the Allocated state. She chooses the attribute name and role, and then sets the following:
-
From state: Allocated
-
Display in this role section: Set
-
Writable at the From state: Set
-
Required when actioned to the To state: Unset
As a result, users with the specified role can view the attribute in their role section and update it when the object is in the Allocated state.
Copy attributes between revisions
For an item attribute, you can set the option that determines whether and how the attribute is copied when a new item revision is created:
Stored per revision, default as specified |
When an item revision is created, Dimensions CM does not copy the attribute values from the previous revision but sets them to the specified default value according to the Default Value. You can subsequently override the values for a specific revision. |
Stored per revision, default to previous revision |
When an item revision is created, Dimensions CM sets the attribute values to those from the previous revision. You can subsequently override values for a specific revision. |
Same for all revisions |
Dimensions CM sets the attribute values for all revisions of the same item to the same value. When you update the value of an attribute for any revision, Dimensions CM also updates that attribute for all other revisions. |
You set this option when assigning an attribute to an item type. For details, see Assign attributes to object types.
See also: