DMCM Process Modeling
DMCM Process Modeling
DIMENSIONS CM 12.2.1 ®
Trademarks
Serena, TeamTrack, StarTool, PVCS, Collage, Comparex, Dimensions, Serena Dimensions,
Mashup Composer, Mashup Exchange, Prototype Composer, Mariner and ChangeMan are
registered trademarks of Serena Software, Inc. The Serena logo, Version Manager,
Meritage and Mover are trademarks of Serena Software, Inc. All other products or
company names are used for identification purposes only, and may be trademarks of their
respective owners.
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
About Serena Dimensions CM is the principal component of the integrated components that constitute
Dimensions the Serena Dimensions product. Other components include:
Dimensions Express, which is an advanced SCM tool that is tailored to the needs of
the developer, and has particular strengths in parallel development and performance.
Dimensions Express helps you organize, manage, and protect your software
development projects on every level—from storing changes to individual files, to
managing entire projects.
Dimension Express provides a focused subset of the functionality available with
Dimensions CM. Additional functionality provided exclusively by Dimensions CM
includes:
• Issue (request) management.
• Process management.
• Deployment management.
• Release management.
• Build management.
• Replication.
• Release management.
• z/OS client.
Serena Dimensions RM, which offers full requirements management and traceability
throughout the development lifecycle by centralizing and organizing requirements
using role base views and a user configurable requirements process.
Purpose of this This manual describes the principles underlying a Dimensions process model and how to
manual create and manage the process model using the Dimensions Administration Console and
the Process Modeling Scripting Interface.
The manual supplies full information on how to construct and tailor a process model for a
particular product. It contains three parts:
Process Modeling Concepts introduces the Dimensions process model and supporting
concepts and terminology. It also provides a high-level overview of defining the
process model for the first time and gives suggestions on how to prepare for this
process. There is also an overview of the Administration Console
Process Modeling Functions describes how to use each process modeling function
using the Administration Console. Chapter 17, "Scripting Interface" on page 279
addresses the Scripting Interface.
Appendixes includes reference material on item, request, baseline, and release
templates, how to manage notification e-mails, and a reference to the Dimensions CM
privileges and rules.
Except where specifically noted otherwise, all the information in this manual is applicable
to the operation of Dimensions under UNIX, z/OS and Windows operating systems.
For more Refer to the Getting Started with Dimensions CM manual for a description of the
information Dimensions CM documentation set, a summary of the ways to work with Dimensions CM,
and instructions for accessing the online help.
Refer to the Administration Console Online Help for descriptions of process modeling
dialog boxes and fields.
For more information on the Process Modeling Scripting Interface, including a full
description of all available process modeling components and respective properties and
methods, refer to the Web-based (HTML) API documentation.
Edition status The information in this guide applies to Release 12.2.1.1 of Serena® Dimensions® CM.
This edition supersedes earlier editions of this manual.
Typographical Conventions
The following typographical conventions are used in the online manuals and online help.
These typographical conventions are used to assist you when using the documentation;
they are not meant to contradict or change any standard use of typographical conventions
in the various product components or the host operating system.
Convention Explanation
italics Introduces new terms that you may not be familiar
with and occasionally indicates emphasis.
bold Emphasizes important information and field names.
UPPERCASE Indicates keys or key combinations that you can
use. For example, press the ENTER key.
monospace Indicates syntax examples, values that you specify,
or results that you receive.
monospaced Indicates names that are placeholders for values
italics you specify; for example, filename.
monospace Indicates the results of an executed command.
bold
vertical rule | Separates menus and their associated commands.
For example, select File | Copy means to select
Copy from the File menu.
Also, indicates mutually exclusive choices in a
command syntax line.
brackets [] Indicates optional items. For example, in the
following statement: SELECT [DISTINCT],
DISTINCT is an optional keyword.
… Indicates command arguments that can have more
than one value.
Printing Manuals
As part of your Dimensions license agreement, you may print and distribute as many
copies of the Dimensions manuals as needed for your internal use, so long as you
maintain all copies in strict confidence and take all reasonable steps necessary to ensure
that the manuals are not made available or disclosed to anyone who is not authorized to
access Dimensions under your Dimensions license agreement.
Platform Support
For details of supported server and client platforms, third party integrations, and Serena
Integrations , see the Serena Release Plan for Dimensions CM at:
http://support.serena.com/Roadmap/Product.aspx?sel=PVDIMENSIONS
Demonstrations
Demonstrations of Dimensions CM features can be viewed at the following public Web
site:
http://courseware.serena.com/dimensions/index.html
http://support.serena.com/
Language-specific technical support is available during local business hours. For all other
hours, technical support is provided in English.
In this Chapter
Design parts are organized into a design part structure by defining hierarchical
relationships between them. Such relationships can be used to express the organization of
your development project to Dimensions CM, providing a structure in which you can
assign roles and responsibilities to specific users. Grouping items within a meaningful
design part structure makes it easier for users to understand how things fit together and
what role they have to play in the success of the development project.
Design Part Dimensions CM has two predefined types of relationship between design parts,
Relationships breakdown and usage.
Breakdown relationships describe ownership of a design part by another design part. Each
design part has a parent that is defined when you create it. Dimensions CM uses
breakdown relationships to determine the inherited responsibilities for the items or
requests associated with a particular design part segment.
Usage relationships express dependencies between design parts, to show where design
parts are reused in the design structure.
Design Part Design parts follow a fixed system-defined lifecycle called LC_PART. You cannot assign
Lifecycle user-defined lifecycles to design parts.
In this example, Will and Sarah inherit the DEVELOPER role on BONUS but do not on
HOLIDAY, since Adam is assigned the DEVELOPER role on that design part.
You can create variants at any level within the product structure. A variant will appear at
the same level as its parent design part.
The Dimensions CM data model provides support for the following object classes:
Design parts (discussed previously)
Items
Requests
Projects/streams
Baselines
Releases
Customers
Items
Items are the components by which a product is implemented and described. Typical
items are source code files, executables, program resources such as graphics, and
specification documents. Entire directories of files can also be items. Items are versioned
objects with full lifecycle support.
Each item is owned by a single design part and may be used by one or more other design
parts. Access to an item is controlled by the role assignments for the design part that
owns it and/or the design parts above that.
Requests
When a problem, bug, or enhancement arises, you can create a request within
Dimensions CM to represent that change or request. Requests help in the development
lifecycle by automating the change process and reducing corrective cycles. Requests also
have lifecycles.
Requests ordinarily affect one or more design parts and have relationships with other
objects such as items and design parts for the purposes of change authorization, change
tracking, and impact analysis.
Work Packages Requests can be grouped into a work package, which is a high-level request for a set of
interrelated changes or tasks. A work package can only be closed once all requests it
contains are closed.
Projects:
Follow a "lock, modify, unlock" mode of working
Can contain parallel sets of changes, or branches, at the same time.
Can support operations that apply to individual items, such as check in or check out.
Streams:
Follow a "copy, modify, merge" mode of working
Only contain one set of tip revisions, or branches, at any one time
Only support operations that process multiple items or folders, such as update or
deliver.
NOTE A stream is configured in the process model as a project of type "STREAM".
References to projects in the Administration Console and in his book refer to projects
generally, and therefore may apply to streams.
In the case of streams, you perform merge operations in the work area, using the Update
function, and the Serena merge tool where merging file content is necessary.
Global Project The global project contains all of the projects/streams and items for the product. Item
operations that are reflected in the global project include create, update, edit, check in,
and delete.
Project/Stream Every project or stream has a folder structure associated with it that consists of
Folders subfolders and items. This folder structure may differ from one project/stream to another.
When a structural change is made to the project/stream directory, the change affects only
that project/stream. For example, any new revision of an item appears only in the project
or stream in which it is created.
Default Work Area Users associate a work area to a project/stream, which is a specific setting to that user
alone. A work area identifies a location outside the Dimensions CM repository for item
files that are copied to and from the repository by functions such as deliver, update, check
out, or check in. Items are placed in the work area relative to their path in the project/
stream. A work area can also be a Dimensions CM-configured object that references a
location on disk.
Baselines
A baseline is a snapshot of a design part segment at a given point in time. This snapshot
is comprised of related design parts and item revisions selected from the current project/
stream. There are three categories of baseline:
Release: A frozen configuration that captures single versions of items in the design
part segment. This configuration typically represents a development milestone within
a product lifecycle and is only done once per project/stream. Item revisions in this
configuration cannot be modified unless the baseline is deleted.
Design: A configuration that captures all revisions of all items in the design part
segment. This configuration is used for reporting purposes. Item revisions in this
configuration can be modified.
Archive: A special type of release baseline that captures item revisions using one or
more *ALL rules in the baseline template. This configuration is used for archive and
retrieval by Dimensions CM.
You can create baselines using a rich set of filtering criteria, including design part, item
type, and status,. You can also create baselines based on requests. When you create a
baseline, Dimensions CM records the status of all items included in it. All items in a
baseline are fully preserved for future use, such as rebuilding the entire configuration or
providing the basis for a new maintenance release.
Baselines are typically used to freeze a configuration within a project/stream for test,
integration, build, or release purposes. They can also be used to meet the audit
requirements for DOD-2167A, ISO9000, SEI Level accreditation, and contractual
commitments to milestone payments.
Like other Dimensions CM objects, baselines have lifecycles. The status of a baseline
reflects the status of the configuration as a whole, for example, PASSED TEST, FAILED
TEST, or READY FOR RELEASE. It provides important management information on the
progress of the project/stream.
Releases
A release is a set of items for the product to be issued to customers. When a baseline
passes testing, it may be considered ready for release to customers using the
Dimensions CM release management facilities. These facilities enable a full or delta
configuration of the product to be copied from the protected Dimensions CM environment
to a release directory. Dimensions CM provides templates that can be applied to the
baseline in order to select the objects for release.
Customers
A customer is the recipient of a release. Dimensions CM can record details on customers
who have received releases of a product and the specific releases which have been issued
to them.
About Lifecycles
A lifecycle defines the approval process for object types in Dimensions CM. You can define
a lifecycle independently and then associate it to an object type in the product's process
model, or you can define a lifecycle from within the context of an object type. Each object
will follow the lifecycle of its associated object type. The status of an object is its current
state in its lifecycle.
A lifecycle comprises:
States: Approval levels through which an object must pass. States typically reflect
process states such as development, test, and release.
Transitions: The permitted movement of an object between one state and another
state. Transitions determine the sequence of states for a lifecycle.
Roles: The role holders who can move an object from one particular state to another,
which is known as actioning.
Normal and off-normal paths: Paths that indicate how an object is progressing
through the lifecycle. The normal path is a linear succession between lifecycles states
that represents a successful path, while an off-normal path represents a failure or a
need for rework.
Lifecycles ensure that an organization's processes are followed and are auditable.
Lifecycles are user-defined so that they reflect the way in which the organization works.
The DRAFT, UNDER REVIEW, and APPROVED states form the normal path for the lifecycle.
WITHDRAWN and REJECTED are off-normal.
A single-state lifecycle has one normal transition with the same begin and end state. An
item assigned to a single-state lifecycle will not appear on any item inboxes.
A privilege is the ability to perform a certain operation on a particular class of object, for
example to create a project, or to action a request. It can also be the ability to perform a
general administrative function, such as to manage lifecycles or privileges.
A role is a set of privileges that can be assigned to one or more users, enabling them to
carry out activities required for a certain position within the organization, for example
Developer, or Team Leader.
For details about privileges and roles and how to use them, see "Privileges and Roles" on
page 45.
About Attributes
Items, requests, baselines, design parts, users, and products have a set of attributes that
are specified in the process model. Attributes record and track important configuration
information such as creation date, owner, status, description, and last updated. You can
view, filter, and report on objects using these attributes.
Some attributes are inherent or system-defined and are always present for a particular
type of object. You can also set up user-defined attributes specifically for your
environment.
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 to suit your processes.
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, and for DB2, up to
56. For greater flexibility, Dimensions CM allows you 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.
The data type determines what kind of information the user can enter as the attribute
value. Below are the valid data types.
an item, request, baseline, design part, or user. Valid sets ensure that users only enter
valid combinations of data into attributes.
A simple valid set contains a single column that lists all of 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 restricts the permissible
values for the other fields in that valid set accordingly.
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 permitted values, Joe White and Fred Gray, for CUST_NAME. 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 setting of the
DM_SMART_ATTR_VALIDATION symbol in the dm.cfg file. If this option is set, the
evaluation of fields in the valid set only takes place from left to right, so that values to the
left of a field are not restricted by what is entered, only values to the right. See the
Administrator’s Guide for more details on the DM_SMART_ATTR_VALIDATION symbol.
For example, for requests of type Problem Report, you could specify that the SEVERITY
attribute is updateable only by a user with the Reviewer role during the DEFINED state.
However, if a rule exists for an attribute with the Writable at the From State setting
enabled for a particular state, then this rule will take precedence and the attribute will
be writable.
If a rule is defined for an attribute as Required when actioned to the To state=yes
for a given From State and To State pair, then the attribute will be displayed as
required in the Dimensions CM Action dialog box when making that transition.
NOTE The Attributes tab in the Edit Attributes dialog box shows required attributes
based on the next lifecycle state (normal or off normal).
Change Managers see all requests as writable and not required, and Product Manager
see all items and baselines as writable and not required.
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.
2 To state, then,
4 Role.
In the example below the attributes rules relating to the attribute PLAN_FINISH are
ordered as follows:
NOTE In versions of Dimensions up to, and including 10.1.3, the attribute rules were
ordered by role; and rules that were non-mandatory took precedence over mandatory
rules. This meant that an attribute rule with no From and To states would take
precedence over one that had specified From and To states.
You can revert to this behavior, by adding the following symbol to dm.cfg on the
Dimensions CM server machine:
DM_ORDER_ATTR_RULES_BY_ROLE
For details see the Administrator’s Guide.
For example, a user with the role Developer will normally be interested in a certain subset
of the user-defined attributes of an item revision, whereas a user with the role Quality
Assurance will be 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; they do not
specify permissions. Any authorized users are permitted to view any of the role sections,
regardless of whether they hold the corresponding roles.
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.
The option that determines how attributes are set between different revisions of the same
item.
Stored per revision, default as specified: when a new revision of an item is created,
Dimensions CM does not copy the attribute values from the previous revision but initially
sets them to the specified default value according to the Default Value above. You can
subsequently override them for a specific revision.
Stored per revision, default to previous revision: when a new revision of an item is
created, Dimensions CM initially sets the attribute values to those from the previous
revision, but you can subsequently override them 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 will also update that attribute for all other revisions.
This is determined when an attribute is assigned to an item type. See "How to Assign an
Attribute to an Object Type" on page 150 for details of how to do this.
Authentication points are generated only for requests and items, and occur when you:
Action an item or request to a sensitive lifecycle state, unless the sensitive state is the
first normal lifecycle state and you are creating the object.
Action an item or request from a sensitive lifecycle state unless the sensitive state is
the first normal lifecycle state and you are creating the object.
Modify the value of a sensitive attribute unless the modification occurs as part of
creating the object.
Delete an item or request when it is at a sensitive lifecycle state.
Authentication points are also generated in the Administration Console when you:
Change a lifecycle state's sensitivity, unless this is done as part of creating the
lifecycle state.
Change an attribute's sensitivity, unless this is done as part of creating the attribute
definition.
Delete a sensitive lifecycle state, including automatic deletions that occur when you
delete the last transition involving the state or delete the entire lifecycle.
Delete a sensitive attribute definition.
See "How to Assign an Attribute to an Object Type" on page 150 for details of how to set
attributes as sensitive.
See "How to Set the State Properties for an Object Type" on page 196. for details of how
to set lifecycle states as sensitive.
About Relationships
Relationships provide traceability between items, design parts, and requests. You can use
relationships to record whether an item is affected by an issue reported in a request or to
specify other items which are derived from, or which are used to derive, an item. You can
also unrelate items, if necessary, depending on the state the item is in.
Relationship types are system-defined or user-defined. If you are the Product Manager,
you can set up user-defined relationship types in the process model.
Item-Item Relationships
Use item-item relationships to signify a dependency or connection between an item and
other items. Items can be related to one another by system-defined or user-defined
relationships. The system-defined relationships are determined by your process model
and cannot be changed.
Created From. An item is created from those earlier item revision(s) from which it
made by merging or editing.
User-defined relationships can also be defined to identify relationships that are specific to
your organization or product.
2 The child item must be open and the parent item must be held or open.
Request-Request Relationships
Use request-request relationships to signify a dependency or connection between a
request and other requests. Requests can be related to one another by system-defined or
user-defined relationships. The system-defined relationships are determined by your
process model and cannot be changed.
User-defined relationships can also be defined to identify relationships that are specific to
your organization or product. These relationships are based on the system-defined
Dependent or Information types.
2 For both Dependent and Information types, the child request must be open and the
parent request must be held or open.
3 For the Dependent type, the request types must both have rules enabled or must both
have rules disabled. See "About Change Management Rules" on page 38 for
information.
4 For the Dependent type, if rules are enabled, then the relationship can only be
established (or dissolved) if the parent request is in the ANALYSIS or An+Work phase,
as described later.
It is found on examination that both the animation and the sound software will need to be
changed. Two new requests are created for these functional areas, and they are related to
the initial request as Dependent.
Item-Request Relationships
You can relate items and requests in order to track which items need to be changed and to
see whether the items have been modified or approved. Items and requests can only be
related to one another by system-defined relationships.
NOTE Valid relationships are not effective if CM Rules have not been set up for a
particular request type. Therefor any request, whose type rules are disabled, may have
any product item revision related to it, provided its item type rules are also disabled.
2 For all relationships types, the item and request must both be open.
3 For the Affected By and In Response To types, the request type and the item type
must both have rules enabled or must both have rules disabled. See "About Change
Management Rules" on page 38 for information.
4 For the Affected By type, if rules are enabled, then the relationship can only be
established (or dissolved) if the request is in the CREATE, ANALYSIS, or AN+WORK
phase.
5 For the In Response To type, if rules are enabled, then the relationship can only be
established (or dissolved) if the request is in the WORK or AN+WORK phase.
The request passed to Jane, the web site manager, who identified the page as
Product_List.html. She relates the existing version, revision 3 of this item to the request
as Affected By.
The changes are assigned back to Sally. When she checks out this item to create revision
4 and update the file, this new revision is automatically related to the request as In
Response To.
The other set of rules, defined for an item type, connects a request lifecycle and an item
lifecycle. These rules require item revisions to be related to requests at various states in
its lifecycle. In this way, CM rules bring version management and change management
closer together, ensuring that related items and requests progress through their lifecycles
in tandem.
You enable rules for specific item types and request types in a product. This means that
the same lifecycle can be reused within the same product or across products with different
rules applied per object type.
There is a per-project override you can apply that can cause item operations taking place
within that project to act in one of the following ways:
To take effect according to whether the CM rules are enabled on the individual item
and request types or not
To behave as if CM rules were enabled for all item and request types
To behave as if CM rules were disabled for all item and request types.
Most rules are related to states on the normal path through the relevant lifecycle.
Valid Relationships Note that rules can only be applied to object types that are allowed to be in valid
relationships. For items, you can specify relationships between two item types. For
requests, you can specify relationships between two requests types or a request type and
an item type.
NOTE A request is described as open when it is in any phase except HELD, CLOSED, or
REJECTED.
Parent-Child Rule In addition to the phases outlined above, you can define a rule regarding parent-child
requests. This rule specifies the minimum state that the request (the child) must reach so
that the parent request can close. Additionally, the parent request can close if the child
document is actioned to the REJECTED phase.
Roles and The tasks permitted in each phase can only be performed by the Dimensions CM users
Permitted Tasks who hold a role on the current state. In the case of the HELD phase, the only authorized
user is the originator. If the leader responsibility is enforced, then only the users with the
leader responsibility can action the request and update its attributes.
Change Managers have additional permissions. They can relate and unrelate objects at
any lifecycle state except the final state, as well as action any request to any of its
lifecycle states. They can also reactivate a closed or rejected request by actioning it to a
non-final state.
The rules for item types and their normal lifecycle states are described below. Note that
rules are only applicable when the related request is on a normal lifecycle path.
NOTE For the New Revision and Action rules, a request must be related In Response To,
which means that a previous revision of the same item must first be related as Affected. If
you cannot fulfill this latter condition, then the Change Manager is allowed to override it
when establishing the In Response To relationship.
During the initial stages of the prototype project, the team disables CM rules for items and
request types. This allows revisions to be freely created and actioned.
Just before delivery, the team enables CM rules to ensure that items in the release
baseline cannot be further developed without request authorization.
Following the delivery of the prototype, the team imposes further controls to prevent any
unauthorized changes being made.
In this Chapter
The purpose of this chapter is to explain how privileges and roles work, the differences
between them, and how you can use them to control which users can perform the various
tasks in your applications and processes.
Managing privileges and roles using the Administration Console is described in "Users and
Roles" on page 83. There is a complete list of the privileges and their associated rules in
Appendix D, "Dimensions CM Privileges" on page 361.
A role consists a collection of privileges that can be assigned to a user or group. For
example, if you are assigned the role of PRODUCT-MANAGER you can perform all the
functions permitted for that role, for example deleting or renaming a product.
Scenario Bill, the Administrator, is a member of the ADMIN group. The ADMIN group have the
privilege Manage Privileges explicitly assigned, therefore he can assign privileges to other
users.
1 He logs into the Administration Console and selects Users and Roles | Privilege
Assignments.
4 He then selects the privileges Delete Project and Update, and sets the same privilege
rules for those privileges.
5 Ted the Team lead, has the role of TEAM LEADER for the product QLARIUS. He logs
into the desktop client and creates a new project PROJA.
7 Bill deletes the project PROJA, as the privilege to do this is specifically assigned to the
ADMIN group.
Some Considerations
When considering the level of process control that you wish to implement you should
consider the following guidelines:
The general grant rules should be sufficient to implement process control for most
users.
Although it is possible to grant or deny privileges to specific users, it is better for
administrative and maintenance purposes, to grant the privilege to a group and
include the user in that group.
NOTE The more rules you enforce the more checks will be needed and this may
impact your system’s performance.
There may be times when you need to correct or undo an action just taken. For such
occurrences you could create a group to perform such semi-administrative tasks, for
example, product level item privileges:
• Move item to another design part
• Action to any state
• Revise item content
For example, a user has actioned an item revision to the next normal state but wishes
to return the item revision to the previous state.
Example
Qlarius, who have small development teams, have decided that their project/stream can
be delivered to by users with any role on the initial lifecycle state transition. To achieve
this general grant rules for the Project/Stream privilege Deliver file into Project/Stream
have been enabled:
Object is in the user's inbox or user has current role
User is the originator of the object
User has any role on the initial lifecycle state transition
In this example, the "Deliver Files into Project/Stream" privilege is checked against the
project/stream into which you are delivering so it checks if:
The project/stream is in the users inbox or the user has a current role on the project/
stream lifecycle, or
They are the originator of the project/stream, or
They hold any role on the product owning the project/stream
Also, by default, this privilege is enabled for anyone in the ADMIN group.
You create a new role or change the privileges for an existing role using the
Administration Console | Privileges and Roles | Role Definitions function. For details, see
"Defining Roles" on page 95.
project
lifecycle transition
Example
Joe and Jane are in the Maintenance group. They need control of the design part called
Pensions. Jim and Mary, in the Development group, need control of the Bonus design part.
You can assign the role of DEVELOPER to both groups, each on their own design part. If
the privilege rule for Update Item Content is set as "user has the DEVELOPER role on the
design part", Joe and Jane are able to update the items for Pensions, and Jim and Mary
can update items for Bonus.
If, in addition, the lifecycle for request type CR has the DEVELOPER role assigned to the
ALLOCATED state, the request will go to Joe and Jane’s inboxes for Pensions, and Jim and
Mary’s inboxes for Bonus.
Inheriting Roles
When a user has a role on a design part, that user also inherits the role on all subordinate
design parts in the design structure, unless a different user is assigned to the same role
on a lower design part. In that case, the latter user assumes responsibility for that design
part and any design parts below it.
Example
John holds the AUTHOR role for design part e. In this case, John is responsible for e and
its subordinate design parts, f and g. Note that only the hierarchical (breakdown)
structure of the design parts determines role assignments. Therefore, John does not
inherit a role on design part d, which is in a usage relationship with design part f. If
someone else gets assigned the AUTHOR role for design part f, then John's responsibility
would be limited to e and g. John may also create items on these design parts if AUTHOR
is specified as the initial role in the lifecycle for the item types.
This allows you to assign some users a role for a particular project/stream in the product
structure, while assigning other users the same role for any remaining projects/streams.
Dawn will then have the DEVELOPER role for the QUOTATION design part in every project/
stream except PROJA, where Dinesh holds this role.
Scenario Dawn has been assigned the role DEVELOPER for design part QUOTATION in Product
PAYROLL.
Ted the Team Leader creates a new project PROJA in product QLARIUS. Dawn is able to
check out file foo.java in PROJA to create a new revision, proja#1
Ted the Team Leader creates another project PROJB in product QLARIUS and has the
administrator assign the DEVELOPER role for PROJB to Dinesh.
Dinesh revises (updates) item foo.java in PROJB to create a new revision projb#1
When Dawn tries to check out item foo.java;B#1 she does not have the required role
because this revision is belongs to PROJB, and Dinesh has the DEVELOPER role for any
items belonging to PROJB.
For example, if the role of TEAM LEADER has the privilege to create baselines, and Ted is
assigned the role of TEAM LEADER for design part QUOTATION, he can create a new
baseline from design part QUOTATION or one of its subordinate design parts.
The Take roles from all affected design parts option allows you to specify whether a
request type should be routed to the role holders on the common ancestor of related
design parts, or to the union of the role holders on all related design parts.
The effect of the Take roles from all affected design parts option is shown in the table
below.
In this case, Will is granted the DEVELOPER role for the USA variant of the APPLICATIONS
design part. Sarah is granted the same role for all variants of the APPLICATIONS design
part, except for USA.
To action an item of type source from the Under Work state to Unit Tested, you need to
have the role of DEVELOPER. To action it from UNIT TESTED to APPROVED, you need to
have the role of TEAM LEADER.
Jane has assigned the DEVELOPER role on the PAYROLL product to Bill, and the TEAM
LEADER role to Sam
Bill needs to make a change to the source file calcs.c. He checks out the file, makes his
changes, and checks the file back in. This creates a new revision with a lifecycle state of
UNDER WORK. The item revision appears in his inbox as he is the originator.
After compiling and unit testing the change, he actions the item revision to UNIT TESTED.
Since Sam has the TEAM LEADER role, the item appears in his inbox. Sam performs a
system test on the Payroll product, which is successful. He therefore actions the item
revision for calcs.c to APPROVED.
Delegating Roles
If you need to be able to assign or reassign a role for an item or request, you can assign
delegation candidates for that role. This means that you will choose one or more of those
delegation candidates for a specific item or request at the time that it needs to be worked
on.
For example, there are times when allocating a request that you need to decide who it
should be forwarded to. You may have a large team of developers and only want to
forward the request to one of them. Who you choose may be based on expertise, work
load, absences, and so on.
To allow for this, Dimensions CM allows you to create delegate roles and assign delegate
candidates to such a role. For example, you could create a delegation role called
IMPLEMENTOR, and assign all the appropriate developers to this role. When the team lead
actions this request to the work state, the action wizard allows him to decide who the
request should be assigned to.
Scenario The lifecycle for request type CR has been defined as below.
The transition from Allocate to Work is assigned the role TEAM LEADER, which for the
design part QUOTATION is assigned to Ted. The transition from Work to Test has the role
Implementor assigned to it. For the design part QUOTATION, this role is assigned to
Dawn, Will, and Dinesh as delegation candidates.
1 The Change Review Board (CRB) raise a change request against the QUOTATION
design part. They action this request to the Allocate state.
2 Ted, the team leader, receives this request in his inbox because he has the Team
Leader role on this design part.
4 Therefore, he selects the request in the desktop client and selects Action. In the
Action wizard, he selects WORK as the next state.
5 On the Roles page of the Action wizard, he selects the IMPLEMENTOR role, and then
selects Dawn from the list of available users for that role.
7 The request is actioned to the WORK state, and Dawn, as the delegated user, gets the
request in her inbox.
Whether an object appears in your inbox, and whether you can action it to the next state
can depend on whether the relevant roles are optional or pending as described below.
A role on a lifecycle transition can also be defined as optional. this means that actioning
an object to the transition's from state does not require there to be a user holding that
role. If this option is not set, the actioning will be disallowed if there are no users holding
that role.
Scenario For example, if the lifecycle for the DOC item type has the following transitions defined in
the Administration Console:
1 Bill, who holds the Developer role, updates an item of type DOC.
2 When he has completed his changes, the new revision is at the initial state of Draft.
In the second example below, the lifecycle for the DOC item type has the following
transitions defined:
1 Bill updates an item of type DOC to create a new revision (Draft state). Although
there is no-one with the TESTER role, he is able to do this because the role is optional.
2 After updating the file, he then attempts to action it to the Under Review state.
Because there is no user holding the QA role, Bill receives a message saying that
there is no user holding that role, and is not allowed to complete the action.
Additionally, Dimensions CM allows multiple users to share responsibility for a role, even
within the same product segment and project/stream. When users share a role on a
design part, all users receive e-mail notification and inbox entries when appropriate. To
help enforce levels of responsibility, Dimensions CM allows you to assign one of the
following capabilities to each user:
primary
secondary
leader
Users with the secondary capability act as backup to the user with the primary capability.
They have exactly the same privileges as the user with the primary capability.
Leader
An alternative to assigning primary and secondary capabilities is the leader capability.
This concept mainly applies to requests, where a large group of users may need to
contribute comments without being granted the ability to action the request. This does
not apply to items.
If you assign the leader capability to a user, then you cannot assign the primary capability
to the same user; leader and primary capabilities are mutually exclusive.
If you assign the leader capability, then the remaining users can only:
Relate and unrelate subordinate objects
Add action descriptions
Special Roles
The default roles and their privileges are described in "Default Privileges for Roles" on
page 61. Each role has been configured to enable the user to perform the appropriate
tasks associated with a typical position within your organization. In a new installation they
will have the necessary privileges to allow them to perform the appropriate functions, but
you can change these, or add new roles.
When you create a new base database or upgrade an existing Dimensions 9 installation,
the default grant rules for the Update Files from Project/Stream and Deliver Files
into Project/Stream privileges include the User holds any role on the product
owning the object rule. As a result, there is a security issue where certain users are
able to download and upload files from any project in the product including those to which
they should not have access. To correct this, you must remove the User holds any role
on the product owning the object rule from the grant rules for the Update Files
from Project/Stream and Deliver Files into Project/Stream privileges.
Change Manager
Product:
Override Process Checks
Request:
Create
Prime
Browse
Delete
Update Attachments
Update Request
Add Action Description
Edit Action Description
Delegate
Action to Any State
Action to Next State
Add/Edit Detailed Description
Move
Perform Replication Operations
Relate Request to Request
Relate Request to Design Part
Relate Request to Item
Relate Request to Baseline
Deleter
Deploy-Manager
Project/Stream
Deploy Sub-Project Baseline to Any Stage
Deploy Sub-Project Baseline to Next Stage
Request
Deploy Request to Any Stage
Deploy Request to Next Stage
Item
Deploy Item to Any Stage
Deploy Item to Next Stage
Dev
Item
Revise Item Content
Developer
Network-Administrator
Parts-Controller
Design Part
Create
Delete
Update
Relate Design Part to Design Part
Rename
Suspend
Privilege Manager
Process Management
Manage Privileges
Product Manager
Product
Delete
Update
Rename
Manage Libraries
Manage Object Types
Assign Roles to Users And Groups
Refresh Inboxes for All Users
Perform Mover Deployments
Run Reports
Override Process Checks
Manage Validsets
View Other Users' Privileges
Manage Project/Stream Upload Inclusions/Exclusions
Relate Requests to Requirement
Project/Stream
Create Stream
Delete Stream
Baseline
Create
Delete
Update
Rename
Action to Any State
Action to Next State
Create Archive
Delete Archive
Transfer Baseline In
Transfer Baseline Out
Build from a Baseline
Relate Baseline to Baseline
Release
Create
Delete
Forward to Customer
Item
Create
Browse
Delete
Update
Delegate
Move Item to Another Design Part
Suspend
Rename
Action to Any State
Action to Next State
Relate Item to Item
Relate Item to Design Part
Revise Item Content
Archive
Project Access
QA
Reader
Reg
Release-Manager
Reviewer
Team-Leader
Project/Stream
Create Project
Rename Item Filenames
Create Directories
Delete Directories
Rename Directories
Attach Project as Sub Project
Relate Requests to Project/Stream
Design Part
Create
Request
Update Attachments
Update Request
Delegate
Action to Any State
Action to Next State
Add/Edit Detailed Description
Relate Request to Request
Relate Request to Design Part
Relate Request to Item
TTDim
Request
Relate Request to Request
Relate Request to Baseline
Valid-Set-Manager
Product
Manage Validsets
Workset-Manager
Project/Stream
Create Project
Assign Deployment Areas to Project/Stream
Action to Any State
Action to Next State
Delete Project
Update
Lock
Bypass Locked Project/Stream
Rename
Add Item revisions to Project
Remove Item revisions from Project
Rename Item Filenames
Create Directories
Delete Directories
Rename Directories
Build from a Project/Stream
Audit a Project/Stream
Populate an Area from a Project/Stream
Attach Project as Sub Project
Attach Baseline as Sub Project
Relate Requests to Project/Stream
Update Files from Project/Stream
Deliver Files into Project/Stream
Change CM Rules for Project/Stream
Import Request into Project
Create Stream
Delete Stream
Baseline
Update Files from Baseline
Writer
In this Chapter
you log out, you may, or may not, be presented with the Dimensions CM log in page the
next time you access the Administration Console.
There is also the option to use Smart Card (CAC) authentication. If you are using this
feature, you will be prompted to supply your PIN, and the login credentials from the
certificate on the specified card will be passed to the application.
If you are not using SSO you will not see the Serena Dimensions CM log in page and you
will be presented with a slightly different Administration Console login page.
1 Start your web browser, and type the URL for the Dimensions CM log in page.
The format of the URL is:
http://hostname:port/adminconsole/hostname is the Dimensions CM web
server and port is the web server port number.
2 If you are not already autheticated for SSO, you will be presented with the Serena
Dimensions CM authentication page.
a Make sure your card is inserted, and click the Smart Card Log In button.
b Select the certificate you want to use. If you want to view the details, click View
Certificate.
If you are not using Smart Card log in, Enter your Username and Password, and
click Log In.
4 If your login is successful, or you are already authenticated with SSO, “Your user
name and password has been validated with SSO” will be displayed.
1 Open your web browser and enter the Administration Console URL provided by your
administrator. The format of the URL is:
http://hostname:port/adminconsole/
where hostname is the machine hosting the Administration Console and port is the
web server port number.
Each time you access the Administration Console URL with your browser, you will be
prompted to allow the Administration Console applet to run. Click Yes to allow the
applet to run.
Enter your user ID in the User Name field and password in the User Password
field. These are typically assigned by your administrator.
If you want to check the version of the Administration Console that is installed, or other
system information, click the About link.
3 In the Network Node field, type the name of the remote node or select it from the
list.
4 For Username, type your user name for the remote node.
1 In the Administration Console main window, click the Change DB link at the top right.
3 Select the database from the list and click the Log in button.
The table below describes each tool available in the Administration Console and refers to
the Dimensions CM guide where the tool is documented.
Menu Area: This contains a set of buttons that allow you to perform various operations
on the objects in the Content area.
Navigation Area: This contains icons in a tree structure. You can expand the tree and
select the nodes beneath it. Selecting an icon either displays a list of the objects that are
contained beneath one of these nodes, or the details of an individual Dimensions object in
the content area.
Content Area: This either contains details of a list of objects in a table or contains more
comprehensive details about a specific object.
Status Area: This contains icons and links relating to what you have currently selected
and that you can change by clicking the icons or links.
Button Function
Clicking the Help link aunches the online
help, which contains procedural and
reference information on the Administration
Console features.
Clicking the list button allows you to select:
e-Learning Tutorials. Takes you to a
page where there is a selection of on-
line tutorials.
Serena Customer Support: Takes you to
the support site.
About this Application: Displays details
on the version of Dimensions CM.
Button Function
Logs you out of the Administration Console.
Icon Description
User name and The user ID of the user currently logged in.
Preferences link Click the Preferences link to display the Set User Preferences
dialog box.
Product name The name of the current product. You can click the icon to
change the current product.
NOTE When you log in to the Administration Console under
your user, the current product will be the last one you have
previously set under that user.
Database The name of the base database currently accessed.
Passwords Link Click this link to display the Passwords dialog box to change a
user password.
In this Chapter
About Groups
A group is a set of users to which you can assign a privilege, thus assigning that privilege
to all the users that belong to that group. This provides a manageable way of granting and
denying privileges. For example, you could create a group called DEVELOPMENT, and
assign users USER1, USER2, and USER3 to that group. You could then grant to that group
the privileges to create, browse, and update items, thus giving these abilities to USER1,
USER2, and USER3.
About Privileges
A privilege is the ability to perform a certain operation on a particular class of object, for
example to create a project/stream, or to action an item. It can also be the ability to
perform a general administrative function, such as to manage lifecycles or privileges. A
privilege can be granted to a user, a group, or a role, or be made to apply generally to any
user or under particular rules. For more details see "How do I Manage Privileges?" on
page 46
About Roles
Roles determine:
Who can action an object from one particular state to another in its lifecycle. This is
done by assigning a role to a lifecycle transition for an object type. For details see
"Managing Transitions" on page 197.
Which users can work on a particular product segment. Roles can be assigned to users
at Product or Design Part level, but can also be assigned to a specific design part
variant and/or project/stream. When you assign users to a role on a design part for
example, this assignment allows those users to work on the objects associated with
that design part.
Having been defined, a role can be assigned to a user or a group, thus controlling which
users can perform the various operations on the Dimensions objects in particular parts of
a product. This distinguishes roles from privileges. Privileges determine which users can
perform specified operations on particular object classes within the product as a whole.
For more details about roles, see "How do I Manage Roles?" on page 51
Status area: Displays log in details. See "The Status Area" on page 80.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
The information that displays in the menu, navigation, and content areas varies,
depending on which tab is active and what you have selected. For more details see:
"Users and Groups Tab" on page 86
"Role Definitions Tab" on page 95
"Role Assignments Tab" on page 97
"Privileges Tab" on page 101
"About User and Group Registration" on page 86
Invocation Dimensions Administration Console | Users and Roles | User and Group Registration
Button Function
or Define a new user using the New User dialog box.
Define a new group using the New Group dialog box.
or Copy details of the selected user/group to create a new user/
group using the Copy User or Copy Group dialog box.
or Delete the selected user(s) or group(s).
Button Function
Promote a proxy (auto registered) user to a normal user using
the Promote Proxy dialog box.
1 From the User Registration main window, click the New button: . The New User
dialog box appears.
3 Enter the e-mail address to be used for notification e-mails sent by Dimensions CM to
the user. in the E-mail field.
5 Click the Attributes tab to enter values for custom attributes for this user.
6 If you want the dialog box to remain open after adding the new user, select the Keep
open check box.
2 For Username, type the Windows user name for the user on the Dimensions CM
server.
Follow the instructions for To add a normal user above and enter the user ID of the
dormant user in the ID field.
1 From the User Registration main window, select the proxy user that you want to
promote.
1 From the User Registration main window, select the user that you want to edit, copy,
or delete. You can select multiple users in the content area if you want to edit or
delete a group of users.
Constraints You can only define single-field, single-value attributes for users.
To assign a valid set to a user attribute, the valid set must be defined in the
$GENERIC product.
To assign an attribute:
1 From the Users Registration main window, click the Manage Attributes button:
.
2 In the Manage Attributes dialog box, click the Assign Attribute button: . The
Assign Attribute dialog box appears.
4 If necessary, change the default value for the maximum character length allowed in
the Max Length field.
5 Select the format for the attribute's value from the Data Type list.
6 Enter a field label for the attribute in the User Prompt field.
7 If necessary, change the default values for the display length and height of the
attribute in the Display Length and Display Height fields.
If you remove an attribute that is not in use by another object type, it will be deleted from
the database.
PRIVILEGES Manage Users and Group Definitions
1 From the User Registration main window, click the Manage Attributes button:
2 In the Attributes for User section, select the attribute you want to edit or remove. You
can select multiple attributes to remove a group of attributes.
1 From the Users and Groups tab, click the drop-down list in the navigation area.
1 From the Users and Groups tab, select All Active Users from the drop-down list in
the navigation area.
2 Click the top-level icon: in the navigation area. A summary of all users appears in
the content area.
5 Click OK.
To view all users again, open the User Filter dialog box and click OK without entering any
values.
1 From the Users and Groups tab, select All Groups from the drop-down list in the
navigation area.
2 Click the top-level icon: in the navigation area. A summary of all groups appears
in the content area.
5 Click OK.
To add a group:
1 In the Users and Groups tab, select All Groups from the drop-down list in the
navigation area.
2 Click the New button: . The New Group dialog box appears.
3 Enter the Name for the new group in the Group Name field.
1 In the Users and Groups tab, select All Groups from the drop-down list in the
navigation area.
2 Select the group you want to copy in the navigation area and click the Copy button:
. The Copy Group dialog box appears.
3 Enter the Name for the new group in the Group Name field.
To modify a group:
1 In the Users and Groups tab, select All Groups from the drop-down list in the
navigation area.
2 Select the group in the navigation area and Click the Edit button: . The Edit Group
dialog box appears.
3 If necessary, Edit the description for the group in the Description field.
To add a user, select the name in the Available Users list, and click the >> link to
move it to the Assigned Users list
To remove a user, select the name in the Assigned Users list, and click the <<
link.
To delete a group:
1 In the Users and Groups tab, select All Groups from the drop-down list in the
navigation area.
2 Select the group in the navigation area and Click the Delete button: . The
Delete dialog box appears.
Constraints Role definitions are not constrained to a specific product but can be used throughout
the base database.
You must be the Product Manager or Role Manager to perform role definition and
assignment tasks. Note that Role Managers cannot define or assign the Product
Manager role.
Each role assignment must consist of an existing user, role, and design part.
Primary: The Primary capability for a role in the lifecycle of an object is assigned to
the user regarded in the project as having the main responsibility for that role on the
object. There cannot be more than one Primary user defined for a role (as applicable
to any particular design part or segment of the product structure). If the Primary role
function is assigned to a user, then Leader role capability (described above) cannot be
assigned to the same user.
Secondary: Secondary users are intended to act as deputies for the Primary. They
have exactly the same privileges as the Primary: they can add action comments and
also, unless the Leader capability has been assigned, update the object's attributes
and action it.
Defining Roles
Button Function
Add a new role using the New Role Definition dialog box.
The information displayed in the content area depends on what you have selected in the
navigation area.
1 From the Role Definitions main window, click the New button: . The New Role
Definition dialog box appears.
4 Select the Keep open check box if you want the dialog box to remain open after
adding the role.
Constraints You cannot delete a role while it is specified within any lifecycle.
When you remove a Dimensions user or role from a product, the inbox for that user
does not change. A relevant new user role will be able to carry out those actions.
You cannot copy or edit the ID of an existing role.
When you copy a role, the role assignments of the existing role are also copied to the
new role.
1 From the Role Definitions main window, select the role that you want to edit, copy, or
delete. You can select multiple roles from the content area if you want to edit or
delete a group of roles.
Assigning Roles
Button Function
Switch to the User view to define role assignments by user.
Button Function
Switch to the Design Part view to define role assignments by
design part.
The information displayed in the content area depends on what you have selected in the
navigation area.
NOTE When certain privilege or role assignments are updated in the Administration
Console, the changes may not take effect during existing client sessions because of
privilege caching. In this case, the user will need to restart the client session for the new
privilege settings to apply. This behavior depends on variables that can be set in the
dm.cfg file. For further details, see the Administrator's Guide.
NOTE If you specify a project/stream when assigning a role, this will apply to requests
and baselines, and not just items as was the case in earlier releases of Dimensions. It is
therefore recommended that roles assigned for managing requests or baselines should
not normally be restricted to specific project/streams.
1 From the Role Assignments main window, select the view from which you want to
make the assignment by clicking:
2 If you selected the Design Part view, select the product in which you want to make the
role assignment from the list in the navigation area.
4 Select a user or group from the User/group field, unless you already selected one or
more users or groups in step 2.
5 Select a role from the Project Role field, unless you already selected one or more
roles in step 2.
6 Select a design part from the Design Part field, unless you already selected one or
more design parts in step 2.
9 Select the Keep open check box if you want the dialog box to remain open after
adding the role assignment.
1 From the Role Assignments main window, select the user/group(s), role(s), or design
part(s) from which you want to delete the role assignment(s).
2 In the content area, select the role assignments that you want to delete.
3 Click the Delete button: in the content area. Confirm that you want to delete the
role assignment(s) by clicking Yes.
The list of users or design parts in the navigation area adjusts to the filter.
1 From the Role Assignments main window, select the objects associated with the role
assignments you want to filter.
4 Click OK.
Privilege assignments are defined for the current product in which you are working. When
you create a new product based on an existing product, the privilege assignments are
copied to the new product. You can also set up privilege assignments by setting your
current product to the $GENERIC product. Doing this enables you to use the $GENERIC
product as a template for privilege assignments when creating a new product.
Privileges Tab
Button Function
Switch to the User view to define privileges by users/groups.
Managing Privileges
2 Depending on the dialog box displayed, move the users or groups you want to be
granted or denied into the Granted Users, Granted Groups, Denied Users, or
Denied Groups list:
To add a user/group, select the name in the Available Users/Groups to grant/
deny list, and click the >> link to move it to the Granted/Denied Users/
Groups list
If you do not want to include a user/group, select the name in the Granted/
Denied Users/Groups list, and click the << link.
3 For certain privileges related to deployment, options are displayed that enable you to
grant or deny the privilege for a specific project or stream, deployment stage, or area.
For details, see "How to Grant or Deny Explicit Privileges for Deployment Functions"
on page 104.
2 In the navigation area, select the category to which the privilege belongs from the
list, Administration Privileges, or Product Level Privileges.
3 Expand the folder: for the subcategory to which the privilege belongs in the
navigation tree and select the privilege.
4 In the Explicit Grant/Deny Rules section of the content area, select the User/Group
and click the button.
2 In the navigation area, select the category to which the privilege belongs from the
list, Administration Privileges, or Product Level Privileges.
3 Expand the folder: for the subcategory to which the privilege belongs in the
navigation tree and select the privilege.
4 In the Explicit Grant/Deny Rules section of the content area, click the button
and choose an option: Grant User, Deny User, Grant Group, Deny Group.
5 For Project/stream, if you want the assignment to only apply to a specific project or
stream, click the browse button and select a project or stream.
6 For Stage, if you want the assignment to only apply when the selected project/
stream is at a specific deployment stage, select the stage from the list.
7 If the privilege relates to deployment or rollback, for Deployment Area(s) select the
areas to which the privilege applies from the list.
8 Depending on the dialog box displayed, move the users or groups you want to be
granted or denied into the Granted Users, Granted Groups, Denied Users, or
Denied Groups list:
To add a user/group, select the name in the Available Users/Groups to grant/
deny list, and click the >> link to move it to the Granted/Denied Users/
Groups list
If you do not want to add a user/group, select the name in the Granted/Denied
Users/Groups list, and click the << link.
2 In the navigation area, select the category to which the privilege belongs from the
list, Administration Privileges, or Product Level Privileges.
3 Expand the folder: for the subcategory to which the privilege belongs in the
navigation tree and select the privilege.
4 In the Explicit Grant/Deny Rules section of the content area, select the User/Group
and click the button.
2 In the navigation area, select the category to which the privilege belongs from the
list, Administration Privileges, or Product Level Privileges.
3 Expand the folder: for the subcategory to which the privilege belongs in the
navigation tree and select the privilege.
4 In the General Grant Rules section of the content area, click the button. The
Enable/Disable General Grant Rules dialog box appears.
2 In the Assign Other Grant Rules dialog box move the roles you want to be assign into
the Assigned Roles list:
To add a role, select the name in the Available Roles to Assign list, and click the
>> link to move it to the Assigned Roles list
To remove a role, select the name in the Assigned Roles list, and click the <<
link.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Subscribe groups to a mail event using
the Subscribe Groups dialog box.
1 In the navigation area, select the mail event that you want to subscribe the user to.
3 If you want to apply the subscription to a specific project or stream, use the browse
button to select the Scope to Project/stream. (This option only applies to
deployment-related events.)
4 If you want to apply the subscription to a specific stage in the GSL, select it from the
Stage list. (This option only appears for deployment-related events.)
5 If you want to apply the subscription to a specific area, select it from the Area list.
(This option only appears for deployment and rollback events.)
6 If you want multiple notifications for the same user to be combined into a single e-
mail, select Digest.
7 Select the user that you want to subscribe from the Available Users list. For multiple
users, press CTRL while selecting the users.
9 If you do not want to add a user to the list, select it in the Users to subscribe list,
and click the << link.
10 Click OK.
1 In the navigation area, select the mail event that you want to unsubscribe the group
from.
2 In the content area, select the entry on the Subscriber Users tab.
4 Click OK.
1 In the navigation area, select the mail event that you want to subscribe the group to.
3 If you want multiple notifications for the same group to be combined into a single e-
mail, select Digest.
4 If you want to apply the subscription to a specific project or stream, use the browse
button to select the Scope to Project/stream. (This option only applies to
deployment-related events.)
5 If you want to apply the subscription to a specific stage in the GSL, select it from the
Stage list. (This option only applies to deployment-related events.)
6 If you want to apply the subscription to a specific area, select it from the Area list.
(this option only appears for deployment and roll back events.)
7 Select the group that you want to subscribe from the Available Groups list. For
multiple groups, press CTRL while selecting the users.
9 If you do not want to add a group to the list, select it in the Groups to subscribe list,
and click the << link.
10 Click OK.
1 In the navigation area, select the mail event that you want to unsubscribe the group
from.
2 In the content area, select the entry on the Group Subscribers tab.
4 Click OK.
Profiles are not meant to enforce security. Use privileges to grant or deny access to
features.
There is a default UI profile that is created when you first install Dimensions CM. When
you create a new user, the default UI profile is automatically assigned to that user. You
can change this UI profile, and you can create other UI profiles and assign them to users
or groups.
NOTE When upgrading from a previous version Dimensions CM 12.1, the installer does
not automatically add new functionality to existing user profiles. You may need to add
these functions manually to each existing user profile you have defined.
NOTE There is also another way of determining which objects a user can see in the
Dimensions CM clients. This is by setting an entry in the DM.CFG file. If this option is set,
the clients will only list objects that are owned by products on which the current user
holds a role. For details of how to set this option, see the Administrator's Guide.
PRIVILEGES Manage User Interface Profiles
Invocation Dimensions Administration Console | Users and Roles | User interface profiles
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
The information that displays in the menu, navigation, and content areas varies,
depending on which tab is active and what you have selected. For more details see:
"Profile Definitions Tab" on page 111
"Profile Assignments Tab" on page 113
Button Function
Create a new profile using the New UI
Profile dialog box.
Create a new profile using the details of
an existing profile.
Delete the selected profile.
Defining Profiles
3 Optionally, enter text that describes the profile in the Description field.
4 Click the Views tab and select which views and subviews should be visible with the
profile.
5 Click the Operations tab and select which commands should be visible with the profile.
6 To create another profile after adding this profile, select the Keep open check box.
7 Click OK.
You can now assign the new profile to the appropriate users or groups.
To modify a profile:
1 On the Profile Definitions tab, select the profile that you want to change.
4 Click OK.
The changes are in place the next time the users log on and select the profile.
To delete a profile:
Button Function
Switch to view by users and groups.
Assigning Profiles
5 Click OK.
To assign all profiles to a user or group, select the Profile Names icon.
To assign a profile to a user or group, select a single profile.
5 Click OK.
1 On the Profile Assignments tab, click the Add UI Profile Assignment button:
4 Click OK.
1 On the Profile Assignments tab, click the Users button: or Profiles button:
3 Select the assignments that you want to remove from the content area.
In this Chapter
Constraints You must have one of the Dimensions roles described below:
Product Manager: These roles can perform all part operations and additionally assign
Dimensions user roles within the design structure.
PCMS Part Manager: This role can create and manipulate design parts within the
scope of their role assignment in the design structure.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Define a new design part or design part variant using the New
Design Part dialog box or the New Variant dialog box.
Button Function
Suspend the selected design part.
When you select the top-level icon: , you can do the following in the content
area:
Select a design part to operate on it. Click to select or deselect all of the design
parts in the list.
Print the list of design parts by clicking .
Save the list of design parts as comma-separated values by clicking .
Sort the design parts by clicking the column headings.
When you create a new design part, a breakdown relationship forms between it and the
parent design part. The new design part automatically inherits the role assignments from
its parent, unless you make explicit role assignments on that design part. See "How to
Assign Roles" on page 98 for instructions on how to assign roles to a design part.
PRIVILEGES Create design part
1 From the Design Part Structure main window, select an existing design part to be the
parent of the new design part.
2 Click the New button: and select Part. The New Design Part dialog box
appears.
3 Enter a name for the design part in the Design Part ID field.
NOTE You cannot enter a part ID that contains a colon character “:”.
4 Select a design part type from the Design Part Category list.
7 Click the Attributes tab to specify values for any user-defined attributes for the design
part.
When you define a variant, it will appear at the same level as the original design part with
the same part ID and PCS value. For example:
PAYROLL:REPORTS.A;1 (original)
PAYROLL:REPORTS.EUROPEAN;1 (variant)
PAYROLL:REPORTS.USA;1 (variant)
Once you've defined a variant, you can operate on it like any other design part.
PRIVILEGES Create design part
1 From the Design Part Structure main window, select the design part from which you
want to create a new variant.
2 Click the New button: and select Variant. The New Variant dialog box appears.
5 Click the Attributes tab to specify values for any user-defined attributes for the
variant.
You can break the usage relationship by removing the used design part from the parent
design part.
PRIVILEGES Relate design part to design part
1 From the Design Part Structure main window, select the design part for which you
want to create a usage relationship.
1 From the Design Part Structure, select the design part from which you want to break
a usage relationship.
2 Click the Unrelate button: . The Unrelate From dialog box appears.
3 Select the design part(s) that you want to remove from the selected design part from
the Used Parts list.
1 From the Design Part Structure main window, select the design part you want to edit.
2 Click the Edit button: on the Design Part Details section. The Edit Design Part
dialog box appears.
3 Change the Design part ID or Description field on the General tab or any of the
attribute values on the Attributes tab.
Updating a PCS is not a commonly performed operation. Typically you would use this
command when you want to work on a new version of a design part.
PRIVILEGES Update Design Part
1 From the Design Part Structure window, select the design part that you want to
update.
2 In the Design Part Details section, click the PCS button: . The Update PCS dialog
box appears.
3 Enter the new value for the PCS in the New PCS field.
4 Enter a new description for the design part in the Description field, if necessary.
By moving a design part, note that you are creating a new breakdown relationship
between the design part and its new parent.
PRIVILEGES Relate Design Part to Design Part
Constraints The design part to be moved and the new parent design part must not be suspended.
You cannot move a design part to another product.
The design part must not have any open requests related to it.
1 From the Design Part Structure window, select the design part you want to move.
2 Click the Move button: . The Move Design Part dialog box appears.
3 Select the design part under which you want to move the design part from the New
Parent Design Part list.
Deleting design parts is not a commonly performed operation. Typically you would use
this command for design parts that have been created in error or have never been used.
PRIVILEGES Delete Design Part
NOTE You cannot delete a top-level design part or variant within a product.
1 From the Design Part Structure main window, select the design part you want to
delete.
3 Confirm that you want to delete the design part by clicking Yes in the Delete dialog
box.
Suspending design parts is not a frequently performed operation. Typically you would use
this command for design parts that are no longer used or required.
PRIVILEGES Suspend Design Part
1 From the Design Part Structure main window, select the design part you want to
suspend.
3 Confirm that you want to suspend the design part by clicking Yes in the Suspend
dialog box.
In this Chapter
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Define a new product using the New Product dialog box.
When you select the top-level icon: , you can do the following in the content
area:
Select a product to edit or delete it. Click to select or deselect all of the products in
the list.
Print the list of products by clicking .
Save the list of products as comma-separated values by clicking .
Sort the products by clicking the column headings.
Defining Products
When you create a new product, you use an existing product, or the $GENERIC product to
base its details on. Object type definitions and privilege assignments are copied from that
product.
You can also define values for any product attributes that appear on the Attributes tab.
These attributes must have been previously defined for the product selected in the Based
On field. To define product attributes, use the Administration Console | Object Type
Definitions | Attribute function and assign attributes to the PRODUCT design part
category.
PRIVILEGES Create Product
To define a product:
1 From the Product Definitions main window, click the New button: . The New
Product dialog box appears.
3 Select the product that you want to use as the basis for the new product from the
Based On list.
6 Select a user to be the product manager for the product from the Product Manager
list.
8 Click the Attributes tab to specify values for any user-defined attributes for the
product.
1 From the Product Definitions main window, select the product that you want to edit or
delete.
In this Chapter
For more For a description of valid sets, see Valid Sets of Values on page 43.
information
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Define a new valid set using the New Valid Set dialog box.
Copy details of the selected valid set to create a new valid set
using the Copy Valid Set dialog box.
Select a valid set to view associated details in the content area or perform actions on
the valid set.
Select the top-level icon: to view a summary of all valid sets in the
content area.
When you select the top-level icon: , the content area displays a summary of
the valid sets in the current product. You can:
Select a valid set to edit, copy, or delete it. Click to select or deselect all of the valid
sets in the list.
Print the list of valid sets by clicking
Save the list of valid sets as comma-separated values by clicking
Sort the valid sets by clicking the column headings.
1 From the Valid Sets main window, click the New button: . The New Valid Set
dialog box appears.
2 Enter a name for the valid set in the Valid Set Name field.
3 Enter the number of columns that you want the valid set to be comprised of in the No.
of Cols field.
5 Click the Values tab. The Values tab displays the number of columns that you specified
on the previous tab.
You can return to the General tab to change the number of columns that appear.
1 From the Valid Sets window, select the valid set that you want to edit, copy, or delete.
2 In the Copy Valid Set dialog box, enter the name of the
new valid set in the Valid Set Name field.
Constraint To assign a valid set to a user attribute, the valid set must be defined in the $GENERIC
product.
1 From the Valid Sets main window, select the valid set that you want to assign to an
attribute.
2 On the Used By section, click the Assign Valid Set button: . The Assign Valid Set
wizard appears.
3 Select the object class that the attribute belongs to from the Object Class list.
4 Select a particular type in the object class from the Object Type list.
6 For single-column valid sets, select the name of the attribute to which you want to
assign the valid set from the Attribute list.
1 From the Valid Sets main window, select the valid set that you want to unassign.
2 On the Used By section, select the row with the attribute from which you want to
unassign the valid set.
3 Click the Unassign Valid Set button: and confirm that you want to unassign the
valid set.
In this Chapter
As there are numerous functions. Object Type Definitions is divided into a number of
sections that are presented in different tabs within the content area. More detailed
descriptions of these functions will be given in each section.
PRIVILEGES Manage Object Types
Constraints Object types (item types, request types, baseline types, design part categories, and
project types) cannot be deleted if there are any instances of that type existing within
the product. For request types, this constraint applies to requests located in both the
main and secondary catalogs.
An item type or request type cannot be deleted if its rules are still enabled (see What
are Change Management Rules? on page 170).
NOTE An object type is defined in relation to the currently selected product. If you want
to set up an object class of the same type in different products you will need to define
them separately in each product.
When you create a new product based on an existing product, the object type definitions
are copied to the new product. You can also set up object types by setting your current
product to the $GENERIC product. Doing this enables you to use the $GENERIC product
as a template for object types when creating a new product.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Allows you to create a new object type using the New Object Type
dialog box.
Allows you to create a new object type by copying the details from
the selected object type using the Copy Object Type dialog box.
Allows you to copy the attributes and/or their attribute rules from
another object type using the Copy Type Attributes dialog box.
Baseline Types
Design Part Categories
Project Types
When the top level node, e.g: is selected in the navigation area, the
content area displays a table of details for all the object types in product for the selected
object class. It contains the following:
A button to edit the selected object type's description, and also to edit various
options for item and request types.
A button to display the list of object types as a separate HTML page to print or
save.
A button to display the list of object types as comma-separated values to save as
a text file.
Column headings for the object type fields. Clicking the icon selects or deselects
all the object types in the list. You can change the sort order of the list by clicking the
column headings.
A table of object types with the following details:
Field Description
A check box to select or deselect the object type(s) for the
Check Box operations performed by the toolbar buttons.
The name of the object type. Clicking on the link will open the Edit
Name Object Type dialog box for that object type.
Lifecycle The lifecycle that is assigned to the object type.
Description The description of the object type.
Each section deals with a particular aspect of the object type, and may or may not exist
for a particular object class. It contains a toolbar enabling you to perform certain actions
on those details. Each is discussed under its own topic, listed below:
When you create an object type from scratch, you create it with a name, description and
general options. You can subsequently assign attributes, a lifecycle, and define other
properties using the various sections within Object Type Definitions.
PRIVILEGES Manage Object Types
1 From the Object Types main window, click the New button:
The New Object Type dialog box appears.
2 On the General tab, enter the name and description for the new object type in the
Name and Description fields.
4 If you are creating an item or request type, choose an appropriate option for the
Closest Functional Match field based on the descriptions and the purpose for which
you intend to use it.
6 If you want the dialog box to remain open after adding the new object type, select the
Keep Open check box.
1 In the Object Types main window, select the object type whose details you want to
copy in the navigation area or the content area.
2 Click the Copy button: The Copy Object Type dialog box appears.
3 On the General tab, enter the name of the new object type in the Name field, and
optionally change the existing description in the Description field.
4 Under the Extended Copy options, choose the additional sets of details you want to
copy from the selected object type to the new object type.
5 If you are copying an item, request, or project type, complete the Options tab as
necessary.
6 If you want the dialog box to remain open after copying the object type, select the
Keep Open check box.
Constraints Object types (item types, request types, baseline types, design part categories, and
project types) cannot be deleted if there are any instances of that type existing within
the product. For request types, this constraint applies to requests located in both the
main and secondary catalogs.
An item type or request type cannot be deleted if its Change Management rules are
still enabled.
1 In the Object Types main window, select the object type you want to delete in the
navigation area or the content area.
2 Click the Delete button: . This displays a dialog box asking you if you are sure
you want to delete the object type.
3 Click Yes.
Constraints Only attributes that are not already defined for the destination object type will be copied.
Any attributes rules currently defined for the destination object type will be deleted before
those for the source object type are copied. Also, attribute rules are defined in
relationship to lifecycle rules and states; therefore, only those rules involving attributes
and lifecycle states relevant to the object type will be copied.
1 From the Object Types main window, select the object type to which you want to copy
the attributes and/or rules in the navigation area.
2 Click the Copy Attributes button: in the content area. The Copy Type
Attributes dialog box appears.
3 Select the source product and object type that you want to copy from the Type lists.
4 Select the Copy Attribute Definitions check box and/or Copy Update Rules check
box to specify which details you want to copy.
You set these details when you first create the object type, and they can be displayed and
edited using the General section.
Option Description
When set, users can check out different or the same revisions of an
item in parallel provided that the project owning the item also has
Allow Parallel the Parallel Checkout option set. (See "About Project Type
Checkout Options" on page 144.)
When set, users must enter a comment concerning the reason for
the item revision update before Dimensions will permit the item
revision to be created, updated or checked in. This constraint applies
Require User when creating, updating, editing or checking in an item revision, or
Comment merging two item revisions.
When set, an item identifier is generated automatically when an
Auto-generate item is created. In this case Dimensions will generate a unique
Item identifier. Note that the identifier will be automatically generated
Identifier even if the user enters a value.
When set, item header substitution is enabled when users get a
Enable Item copy of an item or browse an item (but not when checking one out).
Header See Item Format Templates on page 304 for more details concerning
Substitution item header substitution.
When set, either the originator or all users (determined by the
Don't Force Restrict previous Option to Originator check box) can overwrite
new Revision an item at its initial lifecycle state without changing the revision.
Number on Note: When a request is used to apply refactoring changes, new
Checkin revisions are always created.
Restrict When the Don't Force new Revision Number on Checkin check
previous box is set, this check box can be set or unset to specify, respectively,
Option to that either all users or only the originator can perform such
Originator overwrites.
Option Description
When set, the user can action an item to a new, non-terminal state
only if a primary user exists for that lifecycle state.
Enforce If primary role function is assigned to a user, then leader role
Primary Role function (described below) cannot be assigned to the same user i.e.
Constraint primary role and leader role functions are mutually exclusive.
When set, the user can action an item to a new, non-terminal state
only if at least one leader user exists for that lifecycle state.
Enforce If leader role function is assigned to a user, then primary role
Leader Role function (described above) cannot be assigned to the same user i.e.
Constraint leader role and primary role functions are mutually exclusive.
Use the standard Dimensions Algorithm for determining the
numbering of item revisions when a new branch is created. This
means that the first revision of the first new branch of an item will
have ".1.0" appended. For example, a new branch created from
revision 2.1 would be 2.1.1.0 (if a named branch is not used) and
Use standard the next revision in this new branch would be 2.1.1.1, etc.
level If this option is not set, the first revision in a new branch will have
numbering ".1" appended. For example, a new branch created from revision 2.1
scheme for would be 2.1.1 (if a named branch is not used) and the next revision
revisioning in this new branch would be 2.1.2, etc.
For example, you might want to store all binary files in compressed form.
NOTE You cannot enable file compression for delta libraries.
The compress and uncompress commands used by Dimensions CM by default are the
standard Lempel-Ziv compress and uncompress utilities. This default can be overridden
by setting the parameters described below. However, if you do set these parameters to
use another compression utility, it must be consistently used for all such item types.
UNIX
The parameters COMPRESS and UNCOMPRESS in the Dimensions CM initialization file
$DM_PROG/dm.cfg to suitable settings.
Windows
The parameters DM_PARAM_COMPRESS and DM_PARAM_UNCOMPRESS in the
Dimensions initialization file %DM_ROOT%\dm.cfg to suitable settings.
be set or unset in the Options tab of the New/Copy/Edit Object Type dialog boxes. The
options for request types are:
Option Description
When set, users can create a request of this type only if they
have the Create Request privilege. By default this means they
requre a role on the product to have this privilege. Note
Create Requires however, that users can also be granted the Create privilege for
Role requests under General Grant Rules, "Grant to all users".
When set, request attribute and action description history is
saved when actioning to a new state.
If set, the user can browse a request and view it at any
particular action number.
If not set, the user can only browse the request at the current
Save history action number.
Notify Originator When set, Dimensions CM automatically e-mails the request's
on Close originator when a request is actioned to its end lifecycle state.
When set, the user can action a request to a new state only if a
primary user exists for that state.
If primary role function is assigned to a user, then leader role
function (described below) cannot be assigned to the same
Enforce Primary user i.e. primary role and leader role functions are mutually
Role Constraint exclusive.
When set, the user can action a request to a new state only if
at least one leader user exists for that state.
If leader role function is assigned to a user, then primary role
function (described above) cannot be assigned to the same
Enforce Leader user i.e. leader role and primary role functions are mutually
Role Constraint exclusive.
This option affects the way that roles are calculated for the
Request type. When the option is set, the roles will be
calculated on a request of that type by including the role
assignments on all the design parts to which it is related.
When the option is not set, role assignments will be taken only
from the common ancestor design part for all the related
Take roles from all design parts.
affected design For a more detailed explanation, see "How do I Assign Roles to
parts Requests?" on page 54.
Disabled request When set, users cannot create any new requests of this type.
type
NOTE For streams, which are actually a project of type STREAM, some of these options
are grayed-out, and cannot be changed.
Field Description
When set, the numbering of item revisions is
determined by incrementing the last numeral. For
example, if an item is at revision 5, subsequent
revisions would be 6, 7, and so on.
When the option is not set, item revisions are
incremented by appending a period before the new
number. For example, if a branch is created from
revision 5, would be 5.1, 5.2, and so on.
For streams, by default this option is not set, and
Project is trunk cannot be changed.
When set, new revisions are automatically generated
when an item is edited or updated.
When the option is not set, new revisions are not
automatically generated. The user is asked to supply a
revision ID.
Automatic revision For streams, by default this option is set, and cannot
generation be changed.
When set, an item revision in this project can be
checked out by multiple users at a time.
Note that:
This will be overidden by the Allow Parallel
Checkout setting for an individual item type.
(See "About Item Type Options" on page 142.)
This setting will only apply to newly created
projects of this type. To change this option for
existing projects you will need to use the UWA
command. (See the Command-Line Reference
Guide for details.)
For streams, by default this option is not set, and
Parallel check out cannot be changed.
Field Description
This deployment related option determines whether
the stage of item revisions is "local" to this project/
stream or can be affected by changes in other
projects/streams. (Note that this means that the same
item revision could be at a different stage in different
projects/streams.)
If you select this option, the stage of an item
revision in this project/stream is not affected
when the same item revision is promoted/
demoted to another stage as a result of activities
in any other project/stream.
If you do not select this option, when an item
revision in any project/stream is promoted/
demoted to another stage, then the stage of the
same item revision in this project/stream will also
be updated.
Note: The stage of an item revision can also be
changed when it is actioned if its lifecycle states have
Use local stages been mapped to stages in the GSL.
When set, a project of this type will have the option for
CM rules for items in that project set to Always
disabled by default when it is created (but you can
override this). When this option is set for a specific
project, item operations in that project will act as if CM
Rules were not enabled for any item types or request
types.
Always disable CM Rules
When set, a project of this type will have the option for
CM rules for items in that project set to Always
enabled by default when it is created (but you can
override this). When this option is set for a specific
project, item operations in that project will act as if CM
Rules were enabled for all item types and request
types. For details of these CM Rules, see "CM Rules
Section for Items" on page 171.
Always enable CM Rules
When set, a project of this type will have the option
Request required to refactor set by default when it
is created. When this option is set, the user will be
required to provide a request ID when making any
Require change control refactoring changes to the project, such as moving or
when refactoring renaming items or project folders.
NOTE If neither Always disable CM rules nor Always enable CM rules is set, the
default behavior is for items in a project to follow the CM rules as defined for their item
types. For details, see "CM Rules Section for Items" on page 171.
Button Function
Allows you to edit the General details for the object type using the Edit
Object Type dialog box.
Field Description
Name The name that identifies the object type.
Description The description of the object type.
Lifecycle The Lifecycle ID associated with this object type.
Enabled The options that have been set for the object type, indicated by a
Options checked box.
(Only present See "About Item Type Options" on page 142, "About Request Type
for items, Options" on page 143, and "About Project Type Options" on page 144
requests, and for a list and descriptions of these.
projects)
1 From the Object Types main window, select the object type you want to edit in the
navigation area.
3 Click the button in the content area. This will display the Edit Object Type dialog
box.
5 Optionally, if you are editing an item, request, or project type, update the Options tab
for item types, request types, or project types.
Constraints In addition to the Tool Manager and Product Manager, who can update attributes for all
object classes, Change Managers can update request attributes and Part Managers can
update design part attributes.
Attributes Section
The Assigned Attributes section of the content area displays details for the attributes that
are assigned to the object type selected in the navigation area, and consists of:
A Toolbar containing buttons to perform the following functions:
Button Function
Allows you to assign another attribute to the object type using the Assign
Attribute dialog box. It displays two options:
Single Field. This displays the Assign Attribute dialog box.
Multi Field. This displays the Assign Block Attribute dialog box.
Allows you to edit the details of the selected attribute. This displays the
Edit Attribute dialog box corresponding to the type of attribute:
Single Field. This displays the Edit Attribute dialog box.
Multi Field. This displays the Edit Block Attribute dialog box.
Allows you to unassign an attribute from the object type.
Field Description
Check box A check box to select the attribute.
Name The name that identifies the attribute.
The type of attribute (SS = single field, single value; SM = single
Type field, multi-value; MM = multi-field, multi-value).
The name of the block attribute (if any) that this attribute is
Grouped by associated with.
Prompt The field label which is displayed for the attribute.
Data Type The format: char (character), date, or number.
Length The length that is displayed for the attribute.
Field Description
MaxLength The maximum number of characters this attribute can contain.
Whether the attribute is sensitive. This means that the user is
Is Sensitive required to re-enter their password when they attempt to update it.
Valid Set The valid set assigned to this attribute (if any).
There are a total of 220 (Serena-Supplied Runtime RDBMS, Oracle 10g or 11g, or SQL
Server 2005 or 2008) attributes that can be declared for all single-valued and multivalued
attributes. For further details of database dependant schema limits, see the
Administrator's Guide.
To assign an attribute:
1 From the Object Types main window, select the object type you want to assign an
attribute to in the navigation area.
3 Click the button in the content area. This will display the options:
Single Field
Multi Field (block)
4 Choose the required option. The Assign Attribute dialog box or the Assign Block
Attribute dialog box appears.
5 Enter a name for the attribute or attribute block in the Name field.
6 Enter a field label for the attribute or attribute block in the User prompt field.
8 If the Data type is date, and you want to define validation for the date range:
Select before if you want to validate that the entered date must be before another
date attribute entered for the object type. Select the attribute from the list:
Select after if you want to validate that the entered date should be after another
date attribute, and select the attribute from the list.
Select Fixed range if you want to validate that the entered date should be
between two specified date.
• Use the date picker to select the from date and click the tick in the top right to
confirm it
a Select whether you want users to be able to modify or delete rows from the Block
Update Type field.
b In the Attributes in Block fields, add existing single-field, multi-value attributes to
the block as necessary to form the multi-field multi-value (block) attribute.
NOTE If a block attribute contains multi-value (MVA) attributes with assigned
values defined as mandatory, each populated row must have values assigned to
those mandatory attributes when the user enters them. This default behavior is
different from previous releases. You can revert to the previous behavior by setting
the DM_MANDATORY_MVA_ANY_ROW parameter in the dm.cfg file. For details see
the Administrator's Guide.
To unassign an attribute:
1 From the Object Types main window, select the object type you want to unassign an
attribute from in the navigation area.
4 Click the Delete button: in the content area. This displays a dialog box asking
you if you are sure you want to unassign the attribute.
To edit an attribute:
1 From the Object Types main window, select the object type whose attribute you want
to edit in the navigation area.
4 Click the button in the content area. The Edit Attribute or Edit Attribute Block
dialog box appears, depending on what type of attribute you selected.
6 If you want the dialog box to remain open, select the Keep Open check box.
Constraints Please refer to About Lifecycle Management on page 182 for details on constraints in the
use of lifecycles.
Lifecycle Section
The Assigned Lifecycle section of the content area displays details for the lifecycle that is
assigned to the object type, and consists of:
A Lifecycle Details area. This consists of:
A button. This allows you to assign a lifecycle to the object type using the
Assign Lifecycle dialog box.
Details for the assigned lifecycle:
Field Description
Name The name that identifies the assigned lifecycle.
Description The description for the lifecycle.
Graphics The name of the graphic file (if any) associated with the lifecycle.
Used By A list of the object types that are assigned to this lifecycle.
Lifecycle section
To assign a lifecycle:
1 From the Object Types main window, select the object type to which to you want to
assign a lifecycle in the navigation area.
3 Click the Assign button: in the content area. The Assign Lifecycle dialog box
appears.
5 Click OK.
To edit a lifecycle:
1 From the Object Types main window, select the object type whose lifecycle you want
to edit in the navigation area.
3 Click the button in the content area. The Edit Lifecycle dialog box appears.
4 See The Edit Lifecycle Dialog Box on page 191 for details of how to edit the states,
transitions and rules for the selected lifecycle.
5 When you have finished editing, click Close to return to the Object Types main
window.
Dimensions provides functions to list, create, edit or delete item to item relationship
names or request to request relationship names within the base database (i.e. across
products).
PRIVILEGES Manage Item Relationship Names
Button Function
Allows you to add a new item relationship name using the New
Relationship Name dialog box.
Allows you to edit an item relationship name using the Edit Relationship
Name dialog box.
Allows you to delete an item relationship name.
A table of details for each item-item relationship name defined in the base database:
Field Description
Check Box A check box to select the relationship name.
Name The name that identifies the relationship.
Description The description for the relationship name.
A list of the item types that have this relationship name assigned to
Used By them.
Button Function
Allows you to add a new request relationship name using the New
Relationship Name dialog box.
Allows you to edit a request relationship name using the Edit Relationship
Name dialog box.
Allows you to delete a request relationship name.
A table of details for each request-request relationship name defined within the
product:
Field Description
Check Box A check box to select the relationship name.
Name The name that identifies the relationship.
Class The class of relationship: Information or Dependant.
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of relationship name
you want to create.
2 Select an object type in the navigation area and click the Relationship Names tab in
the content area.
3 Click the button in the content area. The New Relationship Name dialog box
appears.
5 For a request type relationship, select the class on which to base the relationship from
the Class list.
6 Optionally, for an item type relationship, enter a description of the relationship in the
Description field.
1 From the Object Types main window, select Item Types from the Object Class list in
the navigation area.
2 Select an item type in the navigation area and click the Relationship Names tab in the
content area.
3 Select the relationship name you want to edit in the content area and click the
button. The Edit Relationship Name dialog box appears.
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of relationship name
you want to delete.
2 Select an object type in the navigation area and click the Relationship Names tab in
the content area.
3 Select the relationship name you want to delete in the content area.
4 Click the Delete button: in the content area. This displays a dialog box asking
you if you are sure you want to delete the relationship name.
5 Click Yes.
Dimensions provides functions to list, define, edit or delete item to request relationships
within the base database (i.e. across products).
PRIVILEGES Manage Object Types
assign these change requests to individual developers for implementation. In this scenario
the originator of the PR may want to assess the progress of the PR in terms of the
minimum status of the CRs that are related to it.
Dimensions CM provides a "status auto-tracking" option in the process model for every
possible pair of parent request types and children request types. When this option is
enabled for a pair such as <PR, CR>, Dimensions CM will track the minimum status of the
related CRs for each PR in a user-defined attribute for PR specified by the project
manager. The value of this attribute may be browsed or reported on using standard
Dimensions CM browse and report facilities.
As well as providing the minimum status information, maximum status may also be
tracked if required. The combination of minimum and maximum status may be used to
provide a better indication of the progress of the requests in general.
Constraints Only requests that are on the normal lifecycle path can have their status combined in
a parent request. If more than two requests are related to the parent request, the
attribute value will be set to the minimum status of those requests that have a status
in the normal path.
For example, "WP_1" has an attribute "min_cn_status" which tracks the minimum
status of requests "CN_1" and "CN_2" that are related to it as Dependent. "CN_1" is
actioned to an off-normal state, so the attribute will contain the status of "CN_2."
If there are no requests related as Dependent, then the minimum status attribute will
be NULL, even if requests were related at some earlier time.
If all dependent requests are off the normal lifecycle path, then the combined status
will be $OFF-NORMAL.
You can only track the minimum status of one type of request by using a specified
attribute for that request. You can use a different attribute to track a different request
type.
The minimum status is only calculated based on requests in direct relationship to the
parent request. It does not take into account the dependents of the child requests.
If requests follow different lifecycle states depending on the design parts they relate
to (see "Advanced Process Model Features" on page 73), then these lifecycles will be
mapped to the product lifecycle to determine the minimum or maximum status. If the
lifecycle states do not have an equivalent product-level lifecycle state, then the states
are mapped to the previous state which does have an equivalent. The exception to
this rule is the first state in a lifecycle, which always maps to the first lifecycle state in
the product-level lifecycle.
In this case, if a request follows the product-level lifecycle and has status "Active" and
another request follows the DP_1 lifecycle and has status "Tested", then the minimum
status is "Active" and the maximum is "Tested".
The DP_2 lifecycle states "Fix", "Done", and "Supplied" do not have an equivalent in the
product-level lifecycle, so "Fix" and "Done" map to "Created", which is the previous state
that maps to an equivalent, and "Supplied" maps to "Released". So, if a request is on the
product-level lifecycle state "Active" and another is on the DP_2 at "Done", then their
combined minimum is "Created" and maximum is "Active."
Button Function
Allows you to add a new valid item relationship using the New Valid
Relationship dialog box.
Allows you to edit a valid item relationship using the Edit Valid
Relationship dialog box.
Allows you to delete a valid item relationship.
A table of details for each valid relationship to other item types defined in the base
database:
Field Description
Check Box A check box to select the relationship.
Whether the selected item type is the Parent or Child in the
Direction relationship with the listed item type.
Product The product to which the item type belongs.
Type The item type.
Relationship The name of the relationship.
Name
A check box that indicates whether a new revision of the child item
Inherit will inherit all the parent relationships associated with the base
Parent revision it is being created from.
A check box that indicates whether a new revision of the parent item
will inherit all the child relationships associated with the base
Inherit Child revision it is being created from.
Button Function
Allows you to add a new valid request relationship using the New Valid
Relationship dialog box.
Allows you to edit a valid request relationship using the Edit Valid
Relationship dialog box.
Allows you to delete a valid request relationship.
A table of details for each valid relationship with other request or item types defined
in the base database:
Field Description
Check Box A check box to select the relationship.
Whether the selected request type is the Parent or Child in the
Direction relationship with the listed request or item type.
Class The object class: Request or Item.
Product The product to which the item or request type belongs.
Type The item or request type.
Relationship The name of the relationship.
A field that indicates whether the minimum status of the request
types related to a the selected request type will be automatically
Min Status tracked and recorded by Dimensions. It contains the name of the
Attribute attribute to contain the recorded Minimum Status.
A check box that indicates whether the maximum status of the
request types related to the selected request type will be
Max Status automatically tracked and recorded by Dimensions. It contains the
Attribute name of the attribute to contain the recorded Maximum Status.
1 From the Object Types main window, select the object type you want to be the parent
of the relationship in the navigation area.
3 Click the button in the content area. The New Valid Relationship dialog box
appears.
1 From the Object Types main window, select the object type that is the parent of the
relationship in the navigation area.
3 Select the valid relationship you want to edit in the content area and click the
button. The Edit Valid Relationship dialog box appears.
4 Edit the inheritance options for a valid item relationship, or the Minimum Status and
Maximum Status fields for a valid request relationship.
1 From the Object Types main window, select the object type that is the parent of the
relationship in the navigation area.
3 Select the valid relationship you want to delete in the content area.
4 Click the Delete button: in the content area. This displays a dialog box asking
you if you are sure you want to delete the valid relationship.
You can define the attribute mappings used for priming requests for a particular product
or across products in the same database.
Priming takes into account any default attribute values set up by the Product Manager or
individual user. Priming also causes the new request to be related to the product design
parts that were affected by the parent request. You can change these relationships after
priming is complete.
The attributes must have been previously defined and declared for both request types.
Button Function
Allows you to set up a new prime mapping for a request type using
the New Prime Mapping dialog box.
Allows you to edit an existing prime mapping for a request type
using the Edit Prime Mapping dialog box.
Allows you to delete a set of attribute mappings.
A table of details for each request type that has attribute mappings defined in the
base database:
Field Description
Check Box A check box to select the attribute mapping.
Product The product to which the request type belongs.
The request type for which the attribute
mappings are defined, that is to which the
Type attributes are to be copied.
1 From the Object Types main window, select the request type from which the attributes
will be copied in the prime operation in the navigation area.
4 On the first page on the New Prime Mapping Wizard, select the product and request
type for the request type to be primed, and then click Next.
5 On the second page on the New Prime Mapping wizard, map the attributes between
the parent and child request types.
NOTE The list of attributes for Child Attribute includes the Detailed Description,
PCMS_CHDOC_DETAIL_DESC, which is not selectable under Parent Attribute. If you
do not specify a mapping for this attribute, it will be copied from the Detailed
Description of the parent request.
1 From the Object Types main window, select the request type from which the attributes
will be copied in the prime operation in the navigation area.
3 Select the prime mapping you want to edit in the content area.
5 Update the attributes to be mapped in the Edit Prime Mapping dialog box.
NOTE The list of attributes for Child Attribute includes the Detailed Description,
PCMS_CHDOC_DETAIL_DESC, which is not selectable under Parent Attribute. If you
do not specify a mapping for this attribute, it will be copied from the Detailed
Description of the parent request.
1 From the Object Types main window, select the request type from which you want to
delete the prime mapping in the navigation area.
3 Select the prime mapping you want to delete in the content Area.
4 Click the button in the content area. This displays a dialog box asking you if you
are sure you want to delete the prime mapping.
5 Click Yes.
Constraints These functions are available for items and requests only.
The template files must have been previously been created outside Dimensions as
described in "Item Format Templates" on page 304 and "Request Format Templates" on
page 304.
What is a Template?
Templates for requests and items are used to view the contents of a request or for item
header substitution, respectively. The functions provided allow you to associate pre-
prepared item header substitution files or request browse template files with a template.
When the template is added or imported, these template files are placed under revision
control by Dimensions CM and are stored in the Dimensions CM database in a manner
similar to items.
Templates for baselines and releases are different in nature and are discussed in About
Baseline and Release Templates on page 206.
It consists of:
A Toolbar containing buttons to perform the following functions:
Button Function
Allows you to add a new template or template revision using the New
Template dialog box.
Allows you to export a template file using the Export Template dialog box.
Allows you to import a template file using the Import Template dialog box.
Allows you to set the selected template as the default for the object type
selected in the navigation area.
Field Description
Check Box A check box to select the template.
Name The name that identifies the template.
Revision The version of the template.
Created by The user who created the template.
Creation Date The date and time the template was created.
Last The user who last imported the template file.
Imported by
Last Import The date and time the template file was last imported.
Date
Whether the template is the default for the selected item/request
Default type.
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of template you want
to create.
3 If you want to create a new revision of an existing template, select the template in the
content area.
4 Click the button in the content area. The New Template dialog box appears.
5 Enter the name and revision number of the template in the Name and Revision
fields.
6 In the Filename field, enter the filename and path of the template file from your
work area, or browse to the location.
7 If you want this template to be the default, select the Default Template check box.
Note that you can also do this when you first create a new template or revision of a
template if you have the required object type selected in the navigation area.
PRIVILEGES Manage Object Types
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of template you want
to set as default.
3 Select the template you want to make the default in the content area.
4 Click the button in the content area. The Set Default Template dialog box
appears, asking you if you are sure you want to set the template as default.
5 Click Yes.
To delete a template:
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of template you want
to delete.
4 Select the template revision you want to delete in the content area.
5 Click the button in the content area. A dialog box is displayed asking you if you
are sure you want to delete the template.
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of template file you
want to import in the navigation area.
4 Select the template revision for which you want to import a template file in the
content area.
5 Click the button in the content area. The Import Template dialog box appears.
6 Enter or browse to the file you want to import in the Filename field.
1 From the Object Types main window, select Item Types or Request Types from the
Object Class list in the navigation area, according to the type of template file you
want to export in the navigation area.
4 Select the template revision for which you want to export the template file in the
content area.
5 Click the button in the content area. The Import Template dialog box appears.
6 Enter or browse to the file to which you want to export the template in the Filename
field.
A request cannot be related to another request if rules are in force for one of their types
and not for the other.
Specify the minimum state an item must be in before an associated request can be
closed.
These rules will apply to item types and request types for which the CM rules enabled
option has been set. They can also become applicable to item operations in projects which
have the CM rules Always enabled option set.
For an explanation of the effect of Change Management Rules, see About Change
Management Rules on page 50.
Button Function
Allows you to edit the CM Rules for the selected item type using the Edit CM
Rules dialog box.
Details for the item type selected in the navigation area consisting of:
Field Description
CM Rules Enabled? Whether CM Rules are enabled for this item type.
Require Request for new If this option is set, a new item of this type can be
Item created only when in response to a valid request.
Require Request when The first lifecycle state at which a request is mandatory
check out at or beyond for checking out a new revision of the item.
this state
Require Request when The first lifecycle state at which a request is mandatory
action at or beyond this for the item to progress by way of actioning.
state
Require that item must The minimum state an item must reach before requests
be at or beyond this state related to it as IN RESPONSE TO can be closed.
before permit closing of
associated request
A diagram of the normal states of the lifecycle
Lifecycle: associated with the item type.
Button Function
Allows you to edit the CM Rules for the selected request type using the
Edit CM Rules dialog box.
Allows you to view the phase usage for the selected request type using
the CM Phase Usage dialog box.
Details for the request type selected in the navigation area consisting of:
Field Description
CM Rules Enabled? Whether CM Rules are enabled for this request type.
Analysis Phase The first lifecycle state in the Analysis phase.
starts with State
Work Phase starts The first lifecycle state in the Work phase.
with State
Frozen Phase starts The first lifecycle state in the Frozen phase.
with State
If the request type is the child of another request, then this
Minimum State of lifecycle state specifies the minimum state at which this
Child before permit child request must be before the parent request may be
Parent to close closed.
Field Description
Allow request to be Requests can be closed/actioned to a frozen phase without
closed with affected having an in-response-to item relationship.
item revisions
A diagram of the normal states of the lifecycle associated
Lifecycle: with the request type.
1 From the Object Types main window, select the request or item type whose CM Rules
you want to edit.
3 Click the button in the content area. The Edit CM Rules dialog box appears.
5 For item types, set the rules to coordinate items with request states in the Require
Request Rules section.
6 For request types, map lifecycle states to phases in the Lifecycle Phase Rules
section, and set the Dependent Request Rule.
1 From the Object Types main window, select the request type whose CM phase usage
you want to view.
3 Click the button in the content area. The CM Phase Usage dialog box appears.
4 When you have finished, click Close to return to the Object Types main window.
Item Libraries
Constraints To maintain the integrity of the library data, follow these precautions:
Do not use the directories that store Dimensions CM libraries for any non-
Dimensions CM files or subdirectories.
Use each library for items of one or more types that belong to a single product.
Make sure that there is adequate disk space available. Any disk-space quota limits, if
enforced, must be sufficient.
Keep library names well within any operating system limits, such as the total filename
length and number of subdirectory levels. In general, keep directory names to 50-
60% of any operating system limits.
Make sure that you do not use the same directory name for Dimensions CM libraries in
multiple Dimensions CM databases. This would cause Dimensions CM to be unaware
of potential clashes with filenames when operating on any of these databases.
The Product Manager is permitted to revise the library definitions in this function at any
time. However, Dimensions CM will not move the library contents to correspond with the
revised definitions – it merely issues a warning message advising the Product Manager of
the need to do this. Therefore, the definitions must not be altered while other
Dimensions CM users are logged in and using them: to do so would be likely to
cause Dimensions to report fatal library access errors. After making alterations here, the
Product Manager must transfer the files in the library directories so they correspond with
the new definitions before permitting other users to access the libraries for this product.
Item libraries can be stored on remote servers accessed using UNC path names, or via
mapped drives. These could be a Windows Network Access Storage (NAS) a fibre
connected storage area network (SAN) or a network share on a PC.
NOTE It is strongly recommended on UNIX platforms that the Item Libraries are owned
by the Dimensions CM Admin account and not by root.
When you define item libraries, Dimensions CM creates any directories and subdirectories
which do not already exist.
If Dimensions Network is installed and running, the host IDs (up to 20 characters and
case-sensitive) define the node on the network where the item libraries will be located.
The Tool Manager predefines these host IDs when setting up and maintaining the
Dimensions Network. You must choose a node for the item library; * is not a valid entry. If
you enter a node that is not known to Dimensions Network, you will receive an error
message when you attempt to create the library.
If Dimensions Network is not installed, all filenames must be on the local node. To ensure
this, enter the node name of the Dimensions CM server in the combo box.
For libraries located on a UNIX system, the directory path must be an absolute path
ending with a /, for example:
/usr/user1/libraries/type_src/
For libraries located on a Windows system, the directory path must be a an absolute path
ending with a \, for example:
c:\usr\user1\libraries\type_src\
For libraries located on z/OS, refer to the document Dimensions for z/OS User's and
Administrator's Guide for details on creating VSAM datasets and bringing these datasets
'online'. For details of defining nodes using the Network Administration Tool, refer to the
Administrator's Guide.
About Protection
The Protection field is used to modify, if desired, the default protections assigned to an
item library when it is created (see also note below regarding library ownership).
NOTE The required protection level of the directories which hold the Dimensions CM
libraries must be appropriate for the operating system on the network node where the
library is being defined. If the Dimensions Network is being used, this node could be
using a different operating system from the one on which Dimensions CM is running.
Libraries held on UNIX
The Protection field specifies what access to the Dimensions CM libraries is permitted
directly via the operating system. The normal access indicators:
UNIX: R = read, W = write, X = execute
are used in appropriate combinations to provide the required level of protection. The
format in which the protection is defined to Dimensions CM is:
on UNIX: <owner>, <group>, <world>
e.g. RX,RX,
In the examples above, "world" has no access indicators and, therefore, no access to
the directory (except for access to Dimensions CM items via Dimensions CM control).
Libraries held on Windows systems
This Protection field is left blank during library creation. Once a library directory has
been created, and before it is used, its owner (the Product Manager) specifies the
protection level required for operating-system access by creating an ACL (Access
Control List) for it.
It consists of:
A Toolbar containing buttons to perform the following functions:
Button Function
Allows you to define the item library that is assigned to the selected item
type using the Add Specific Library dialog box.
Allows you to edit the item library details assigned to the specific item
type using the Edit Specific Library dialog box.
Button Function
Allows you to delete the library definition for the selected item type.
Allows you to define the default item library for the whole product using
the Add Default Library dialog box.
Allows you to edit the details of the default item library for the whole
product using the Edit Default Library dialog box.
Allows you to delete the default item library definition.
Details for the item library associated with the selected item type. This may be the
default library for the product, or it may be the specifically assigned library for the
selected item type if one has been created. The following details are displayed:
Field Description
The name that identifies the network node where the item library is
Host Name held.
Directory The path of the directory on the host node where the library is held.
Whether the items are stored using the native Serena Version
Delta Storage Manager delta library storage scheme.
The required protection level of the directories which hold the
Protection Dimensions CM libraries.
Default Whether this library is the same as the default for the product.
1 From the Object Types main window, select an item type in the navigation area.
If there is no default item library set up, click the right-most button in the
content area. (The right-most button will be grayed out). The Add Default
Library dialog box appears.
If there is a default item library set up, click the right-most button in the
content area. (The right-most button will be grayed out). The Edit Default
Library dialog box appears.
4 Select the network node that holds the item library from the HostName list.
5 Enter the directory path to the item library on the host node in the Directory Path
field.
CAUTION! Item libraries must not reside in the root directories of Windows drives
or shares! This is unsupported, and may cause many operations to fail.
CAUTION! When the Dimensions server is installed on Windows 2008 server, item
libraries cannot be located in the folders beneath the Program Files folder.
NOTE If you change the location of the item library, Dimensions CM does not relocate
the contents of the existing library to reflect this change. You will need to move the
library files manually to the new location.
Purpose Follow this procedure when you want to create or edit the Item Library Definition for a
specific item type. This will override the default library.
PRIVILEGES Manage Libraries
1 From the Object Types main window, select the item type for which you want to define
a library in the navigation area. Make sure the Item Libraries section is displayed in
the content area.
3 Select the network node that holds the item library from the HostName list.
4 Enter the directory path to the item library on the host node in the Directory Path
field.
CAUTION! Item libraries must not reside in the root directories of Windows drives
or shares! This is unsupported, and may cause many operations to fail.
CAUTION! When the Dimensions server is installed on Windows 2008 server, item
libraries cannot be located in the folders beneath the Program Files folder.
NOTE If you change the location of an item library, Dimensions CM does not relocate the
contents of the existing library to reflect this change. You will need to move the library
files manually to the new location.
Purpose Follow this procedure when you want to delete the default Item Library Definition for the
product.
PRIVILEGES Manage Libraries
1 From the Object Types main window, select an item type in the navigation area.
3 Click the right-most button in the content area. A dialog box is displayed asking if
you are sure you want to delete the default item library.
1 From the Object Types main window, select the item type for which you want to delete
the library in the navigation area.
3 Click the left-most button in the content area. A dialog box is displayed asking if
you are sure you want to delete the item library.
In this Chapter
Constraints The role titles defined in each lifecycle transition must have been previously defined
(except for $ORIGINATOR). See How to Add Roles on page 96 for details.
A lifecycle can be deleted only if no object types in any product currently specify it.
A different lifecycle ID may be specified for an object type, or the lifecycle relationship
may be deleted, only if there are no objects of that type already existing.
You edit the states, transitions, and associated roles and rules for a lifecycle using the Edit
Lifecycle dialog box. This is described in more detail in The Edit Lifecycle Dialog Box on
page 191.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Allows you to create a new lifecycle using the New Lifecycle dialog box.
Allows you to create a new lifecycle by copying the details from the
selected lifecycle using the Copy Lifecycle dialog box.
All Lifecycles
Requests
Items
Projects
Baselines.
Field Description
A check box to select or deselect the lifecycle for the operations
Check Box performed by the toolbar buttons.
The name of the Lifecycle. Clicking on the link will open the Edit
Name Lifecycle dialog box for that lifecycle.
Description The description of the lifecycle.
Creation Date The date and time the lifecycle was created.
Originator The user who created the lifecycle.
Button Function
Allows you to assign object types to a lifecycle using the Assign
Object Types to Lifecycle dialog box.
Allows you to edit the description for the selected lifecycle using the
Edit Lifecycle Properties dialog box.
Field Description
Name The name of the lifecycle.
Description The description of the lifecycle.
User Name The user who created the lifecycle.
A comma-separated list of the object types that use the lifecycle.
Clicking on the name link opens the Edit Lifecycle Dialog box
Used By with that object type selected in the Object Types filter.
It consists of:
A Toolbar containing buttons to perform the following functions:
Button Function
Allows you to add a new associated image using the New Lifecycle Image
dialog box.
Allows you to export an image file associated with a lifecycle to your work
area.
Allows you to import an image file using the Import Lifecycle Image dialog
box.
Allows you to delete an associated image for the lifecycle.
Allows you to set the selected image as the default for the lifecycle
selected in the navigation area.
Field Description
Check Box A check box to select the image.
Revision The version of the image.
Created by The user who created the image.
Creation Date The date and time the image was created.
Last The user who last imported the image file.
Imported by
Last Import The date and time the image file was last imported.
Date
Is Default Whether the image is the default for the selected lifecycle.
You can ether create a new lifecycle from scratch, or you can base it on an existing
lifecycle. When you copy an existing lifecycle, its states and transitions are copied to the
new lifecycle.
The New Lifecycle dialog box or Copy Lifecycle dialog box appears.
2 Enter the name of the lifecycle in the Name field, and optionally a description in the
Description field.
To define further details for the lifecycle, such as states, transitions, and attribute rules,
see About Editing Lifecycles on page 191.
Constraints A lifecycle can be deleted only if no object types in any product currently specify it, and if
all its state transitions have first been deleted.
1 In the Lifecycles main window, select the lifecycle(s) you want to delete.
2 Click the Delete button: You will be prompted with a dialog box asking you to
confirm the deletion.
3 Click OK. Dimensions CM deletes the lifecycle(s) and removes them from the list.
Note that you can also assign a lifecycle to a specific object type in the corresponding
dialog boxes in Object Type Definitions. See About Assigning Lifecycles to Object Types,
described on page 153.
PRIVILEGES Manage Lifecycles
Constraints You cannot assign a lifecycle to an object type that already has a lifecycle assigned to it.
1 In the Lifecycles main window, select the lifecycle to which you want to assign object
types.
2 Click the assign button: The Assign Object Types to Lifecycle dialog box appears.
3 To assign object types, select them from the Available object types list and click
Relate.
Note that you can also unassign a lifecycle from a specific object type in the
corresponding dialog boxes in Object Type Definitions. See Assigned Lifecycle Details,
described on page 153.
PRIVILEGES Manage Lifecycles
A different lifecycle ID may be specified for an object type, or the lifecycle relationship
may be deleted only if there are no objects of that type already existing.
1 In the Lifecycles main window, select the lifecycle from which you want to unassign
object types.
2 Click the Assign button: The Assign Object Types to Lifecycle dialog box appears.
3 Select the object type(s) you want to unassign in the Object types associated with
this lifecycle list and click Unrelate.
1 In the Lifecycles main window, select the lifecycle to which you want to assign object
types.
2 Click the Edit: button. The Edit Lifecycle Properties dialog box appears.
1 In the Lifecycles main window, select the lifecycle for which you want to view the
image in the navigation area. This will display its details in the content area.
2 Select the revision for the image you want to view in the Lifecycle Images section of
the content area.
3 Click the button in the content area. The image will be displayed in a new
browser window.
1 From the Lifecycles main window, select the lifecycle in the navigation area.
2 Click the button in the Lifecycle Images section of the content area. The New
Lifecycle Image dialog box appears.
3 Enter the version number of the image file in the Revision field.
4 Enter or browse to the filename and path of the image in the Filename field.
5 Optionally, select the Default Image check box to make this image the default for
the lifecycle.
6 When you have finished, click OK. The details of the new image appear in the content
area.
Note that you can also do this when you first create a new image or revision of an image.
PRIVILEGES Manage Lifecycles
1 From the Lifecycles main window, select the lifecycle for which you want to set the
default image in the navigation area.
2 Select the revision you want to make the default in the Lifecycle Images section of the
content area.
3 Click the button. The Set Default Image dialog box is displayed asking you if you
are sure you want to set the template as default.
1 From the Lifecycles main window, select the lifecycle for which you want to delete the
associated image in the navigation area.
2 Select the revision you want to delete in the Lifecycle Images section of the content
area.
3 Click the button in the content area. A dialog box is displayed asking you if you
are sure you want to delete the image.
1 From the Lifecycles main window, select the lifecycle for which you want to import the
associated image in the navigation area.
2 Select the revision for which you want to import the file in the Lifecycle Images
section of the content area.
3 Click the button in the content area. The Import Lifecycle Image appears.
4 Enter or browse to the filename and path of the image you want to import in the
Filename field.
1 From the Lifecycles main window, select the lifecycle for which you want to export the
associated image in the navigation area.
2 Select the revision that you want to export in the Lifecycle Images section of the
content area.
3 Click the button in the content area. The image will be displayed in a new
browser window.
4 Use the Save As function of the browser to save the image to your work area.
Button Function
Allows you to delete a normal state. For details, see How to Delete a
Normal State on page 195.
Allows you to rename a state. For details, see How to Rename a State on
page 196.
Allows you to set up or edit the CM rules for the selected state. This is only
appears if a request type has been selected in the object type filter. For
details, see How to Define CM Rules on page 195.
Allows you to configure a lifecycle state as a stage in Dimensions Build or
to define the state as sensitive. This is only appears if an item or request
type has been selected in the object type filter. For details, see How to Set
the State Properties for an Object Type on page 196.
Allows you to assign object types to a lifecycle. For details, see How to
Assign Object Types to a Lifecycle on page 187.
You can select a state by clicking it or by choosing it in the State filter. The arrows
representing the possible transitions into that state become highlighted in light blue, and
the transitions out of it become highlighted in dark blue. When a state is selected, the
Transitions area only shows the possible transitions to and from that state, whereas when
no state is selected all the transitions for the lifecycle are shown.
When a request type is selected in the Object Type filter, and phases have been defined
for that request type, the phases are shown as a gray background against the lifecycle
states to which they apply.
When an item type is selected in the Object Type filter, and build stages have been
configured for Dimensions Build for that item type, the build stages are shown as a gray
background against the lifecycle states to which they apply.
If a lifecycle state has been defined as sensitive, this is indicated by the following icon:
You can create a new transition by clicking in one state and dragging the mouse pointer
into another state. This displays New Transition dialog box.
A request cannot be related to another request if rules are in force for one of their types
and not for the other.
1 From the Lifecycles main window, click the top level node: in the
navigation area.
2 Click the name link of the lifecycle associated with the request type in the content
area. The Edit Lifecycle dialog box appears.
3 Select the request type for which you want to define the rules in the filter bar.
5 Click the Phases: button. This will display the Edit CM Rules dialog box.
7 Map lifecycle states to phases in the Lifecycle Phase Rules section, and set the
Dependent Request Rule.
Note that you do not need to delete off-normal states as they are removed when there are
no transitions that involve them.
PRIVILEGES Manage Lifecycles
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle associated with the object type in the content area.
The Edit Lifecycle dialog box appears.
3 Select the state you want to delete in the upper row of the Lifecycle Model.
4 Click the Delete button: You will be prompted with a dialog box asking you to
confirm the deletion.
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
Also follow this procedure to associate an item type with a stage in the Global Stage
Lifecycle.
PRIVILEGES Manage Object Types
You can only assign a deployment stage to a state if no other deployment stage is
assigned to it.
You cannot assign or unassign a deployment stage other than DEVELOPMENT to or from a
lifecycle state if there are item revisions in the base database that:
have item types following this lifecycle
and
are currently at this lifecycle state
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle associated with the object type in the content area.
The Edit Lifecycle dialog box appears.
3 Select the item or request type whose state properties you want to set in the filter
bar.
4 Select the state for which you want to set the properties and click the Properties
button:
6 For an item, request, or baseline type, select the stage you want to associate with the
lifecycle state from the Stage list. If you want to remove the association, select <No
Stage Assigned>.
7 Click OK.
NOTE If you have changed the Is Sensitive option, you will be presented with an
Authentication Point dialog box. Enter your Dimensions password and click OK.
Managing Transitions
About Transitions
A transition is a pair of lifecycle states between which it is possible to action the object.
For each possible transition, you specify one or more roles. A user must have one of these
roles in order to action the object from the from state to the to state.
In addition to this, there are two options associated with each role for a transition:
Optional. If this option is set, this means that actioning an object to the transition's
from state does not require there to be a user holding that role.
If this option is not set, the actioning will be disallowed if there are no users holding
that role.
Pending. If this option is set, the object will appear in the user's inbox, and the user
will receive an e-mail notification when the object is actioned to the from state for the
transition.
If this option is not set, it will not appear in the user's inbox and the user will not
receive e-mail notification, but the user will still be able to perform the action.
For further details and an example, see "Assigning Pending and Optional Roles" on page
58.
Transitions Area
The Transitions area of the Edit Lifecycle dialog box displays the possible transitions in or
out of the state you have currently selected in the Lifecycle Model. If you have selected a
specific object type in the Filter bar, it also lists each attribute for which a role has a
defined rule. If no state has been defined, it displays all transactions for all states of the
lifecycle.
It consists of:
A toolbar
A table of transitions and roles.
Button Function
Allows you to add a new transition using the New Transition dialog
box.
Allows you to edit a transition using the Edit Transition Lifecycle
dialog box.
Allows you to delete one or more transitions.
The table of transitions and roles contains a row for each combination of transition with
each role that is authorized to action the object type(s) through this state. If a role is
selected in the role filter, only that role will appear in the list.
Next to each role, there is an icon indicating whether the role is optional or pending.
Icon Meaning
O Optional. This means that actioning an object to the transition's from state
does not require there to be a user holding that role.
If the role is not optional, the actioning will be disallowed if there are no
users holding that role.
P Pending. The object will appear in the user's inbox and the user will receive
e-mail notification when the object is actioned to the from state for the
transition.
If the role is not pending, it will not appear in the user's inbox and the user
will not receive e-mail notification, but the user will still be able to perform
the action.
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
4 Select the states in the transition in the From State and To State fields. To create new
states, enter them in the fields.
NOTE An existing normal transition can be split by creating a normal transition that
inserts a new state within the lifecycle path. If this is the case, the existing transition
will be adjusted, but you will be prompted with a message asking you to confirm this
before the new transition is created.
5 If the transition is a normal one, select the Is a Normal Transition check box.
6 Select the roles for the transition from the Roles list and specify if you want the roles
to be optional and/or pending.
7 If you want the dialog box to remain open, select the Keep Open check box.
To edit a transition:
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
3 Select the state for the transition you want to edit in the Lifecycle Model.
4 Select the transition in the Transitions area and click the Edit Transition button:
To delete transitions:
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
3 Select the state for the transition you want to delete in the Lifecycle Model.
4 Select the transition(s) you want to delete in the Transitions area and click the Delete
Transition button: You will be prompted with a dialog box asking you to confirm
the deletion.
5 Click OK to delete the transition(s). Any off-normal states that no longer have any
transitions to or from them will also be removed.
Allows you to add a new rule. For details, see How to Create a
New Attribute Rule on page 201.
Allows you to edit a rule. For details, see How to Edit an
Attribute Rule on page 202.
Allows you to delete one or more rules. For details, see How to
Delete Attribute Rules on page 203.
The table of attributes and roles contains a row for each combination of attribute and role
that has a rule. If a role is selected in the role filter, only rows for that role will appear in
the table.
Required Means required. The attribute must have a value before the object
type can be actioned to a new state.
Writeable Means updatable. The attribute can be updated by this role when
the object type is at this state.
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
3 Select the Object type for which the rule is to apply in the Object Type field in the
filter bar.
4 Optionally, select the state to which you want to add the attribute rule in the Lifecycle
Model.
5 Click the Add button: The New Attribute Rule dialog box appears.
6 Select the attribute for which you want to create a rule from the Attribute name list.
7 Select a state from the From state list. If you want the rule to apply to a transition,
select a state from the To state list.
NOTE The From state and To state must belong to the same transition. An attribute
rule only applies to a single transition.
10 If you want the dialog box to remain open, select the Keep Open check box.
You can create an attribute rule from scratch or you can copy the details from an existing
attribute rule.
PRIVILEGES Manage Object Types
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
3 Select the Object type for which the rule is to apply in the Object Type field in the
filter bar.
4 Optionally, select the state for which you want to edit the attribute rule in the Lifecycle
Model.
5 Click the Edit button: The Edit Attribute Rule dialog box appears.
1 In the Lifecycles main window, display the list of lifecycles in the content area by
clicking the top node: in the navigation area.
2 Click the name link of the lifecycle in the content area. The Edit Lifecycle dialog box
appears.
3 Select the state for which you want to delete the rule in the Lifecycle Model.
4 Select the attribute/rule row(s) you want to delete in the Attribute Rules area and
click the Delete button: . You will be prompted with a dialog box asking you to
confirm the deletion.
In this Chapter
For an item baseline template, you specify the criteria for inclusion and exclusion of item
revisions by defining a set of rules based on the item's type, revision, status or build
stage, and item relationships.
For a request baseline template, you specify the criteria for inclusion of item revisions
based on a specified group of requests to which the item revisions are related as In
Response To, or optionally Info. You do this by defining a set of rules for the selection of
these requests.
Release and Archive baselines are defined by their associated templates; whereas a
Design baseline is essentially defined by the absence of an associated template in that
the baseline will include all revisions of the items from the top-level design part and its
subordinate design parts (regardless of their status). Baseline templates are unique with
respect to the base database; they are not restricted to particular products. Release
baselines only include one revision of each item. Baselines based on a request baseline
template are always release baselines.
For a full discussion of the concepts underlying baseline and release templates, please
refer to "Baseline Templates" on page 324.
Selection criteria can either be defined as implicit, or can be for a specific normal state or
build stage in the lifecycle.
Description
All revisions
Latest edit revision
Latest edit revision at Final State in Lifecycle
Latest edited revision at the most progressed state
Revision built from selected inputs
Revision that makes selected outputs
NOTE Latest edit revision in this context means the last item revision that was created.
If you choose one of these implicit states as the value for the Lifecycle State field, you
do not require any additional rules, since these are sufficient to determine which revisions
of an item to include. The State Selector field can therefore be left blank.
If you specify a specific lifecycle state for the Lifecycle State field, an additional status
rule will need to be provided in the State Selector field. The options for these additional
criteria are:
If you specify a specific build stage for the Lifecycle State field, an additional stage
related rule will need to be provided in the State Selector field. The options for these
additional criteria are:
Dimensions CM uses these additional rules together with a selected normal lifecycle state
or build stage to determine a grouping and order of preference for the item revisions to be
included in baselines using this template.
When a baseline is created specifying a request baseline template and a set of starting
parent requests, then all the requests that:
are related to those parent requests, and
match the template rules
The template rules will be processed in exactly the same way they are for item templates,
that is, requests will be selected based on the type, status, and the baseline status code
that was specified. For example, if a template had a rule that specified:
all requests of type PR,
at status ACCEPTED,
with the baseline status code EQS
then all the requests of type PR, at the status ACCEPTED only, would be used for inclusion
into the baseline.
Once this list of requests has been determined, then only those items that are related to
those requests with either an InResponseTo or, optionally, an Info relationship will be
included in the baseline. However, because the baseline that is being created is a release
baseline, only one revision of each item will be included in the baseline (not all revisions,
as would be the case for a design baseline). This means, that even though the requests
being selected may contain multiple revisions of the same item, the final baseline can only
contain one revision of all these possible items.
To ensure that only one revision of an item is included in the final baseline in
circumstances where multiple item revisions are related to requests, only the latest item
revision will be selected using that item's pedigree.
When the baseline has been created, the requests that were used to create it will be
related as InResponseTo that new baseline.
specified in a template rule instead of a specific item type, thereby bringing all the
associated item types within the scope of that rule.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Allows you to create a new template, or item type group using
one of the following:
New Baseline Template dialog box
New Release Template dialog box
New Item Type Group dialog box
Allows you to create a new template by copying the details from
a selected one using one of the following:
Copy Baseline Template dialog box
Copy Release Template dialog box
Allows you to delete the selected template, or item type group.
When the top level node: is selected in the navigation area, the
content area displays a table listing all of the baseline templates, release templates, or
item type groups in the base database depending on the selection in the navigation area.
It contains the following:
A button to display the list of templates as a separate HTML page to print or save.
A button to display the list of templates as comma-separated values to save as a
text file.
Column headings for the fields. Clicking the icon selects or deselects all the
objects in the list. You can change the sort order of the list by clicking the column
headings.
A list of objects:
For baseline and release templates, this contains the following details:
Field Description
A check box to select or deselect the template(s) for the
Check Box operations performed by the toolbar buttons.
Template ID The name that identifies the template.
Creation Date The date the template was created.
Field Description
Originator The user ID of the user who created the template
For a baseline template, whether it is an item or request baseline
Scope template.
Field Description
A check box to select or deselect the template(s) for the
Check Box operations performed by the toolbar buttons.
Item Type The name that identifies the item type group.
Group Name
Field Description
Name The name that identifies the template.
Creation Date The date the template was created.
Created By The user ID of the user who created the template
Scope Whether this is an item or request baseline template.
Button Function
Allows you to add a selection criterion using the New Selection
Criterion dialog box.
Allows you to edit the selected selection criterion using the Edit
Selection Criterion dialog box.
Allows you to delete a selected selection criterion.
Field Description
A check box to select or deselect the criterion for the
Check Box operations performed by the toolbar buttons.
The item type for which the selection applies. "*" means
this applies as the default for all item types for which no
Item Type specific item type criteria have been defined.
Associated The lifecycle associated with the item type. This is blank if
Lifecycle Item Type is "*".
Field Description
The state(s) for which the selection criterion applies. This
Lifecycle may be either a specific normal state or one of the implicit
State values.
Additional The criteria to be used when a specific lifecycle state has
Criteria been specified in the Lifecycle State field.
For a further explanation of these fields, see About Item Baseline Template
Selection Criteria on page 207.
• For a request baseline template
Field Description
A check box to select or deselect the criterion for the
Check Box operations performed by the toolbar buttons.
The item type for which the selection applies. "*" means
this applies as the default for all item types for which no
Request Type specific item type criteria have been defined.
Request The status on which the selection criterion is based.
Status
Baseline The rule that determines which requests are selected in
Status Code conjunction with the specified status.
For a further explanation of these fields, see "About Request Baseline Template
Selection Criteria" on page 208.
A Baselines Using Above Template area, containing a table of baselines created
using the selected template. It displays the following for each baseline:
Field Description
Product Id The product to which the baseline belongs.
Baseline Id The ID of the baseline that uses this template.
Creation Date The date the baseline was created.
Created By The user ID of the user who created the baseline.
Field Description
Name The name that identifies the template.
Creation Date The date the template was created
The user ID of the user who created the
Created By template
Button Function
Allows you to add a selection criterion using the New Selection
Criterion dialog box.
Allows you to edit the selected selection criterion using the Edit
Selection Criterion dialog box.
Allows you to delete a selected selection criterion.
Field Description
A check box to select or deselect the criterion for the
Check Box operations performed by the toolbar buttons.
The highest level design part to which the criterion applies.
The same criterion applies to all its subordinate child parts,
unless overridden by a more specific criterion.
"*" means this is the default for all design parts for which no
Part ID specific item type criteria exist.
This field limits the criterion to one variant of the design
parts specified by the Part ID field (plus subordinate design
part variants).
"*" means all variants of the design part will be subjected to
Part Variant the criterion
The item type(s) for which the selection applies. This will
either be a specific item type or the name of an item type
group that has been defined.
"*" means all items will be subjected to the criterion.
Hyphen "–" means that the selection criterion will be not be
Item Type/ applied to any items (i.e. items will not be selected for this
Group criterion).
Release If specified, all item types selected by this criterion will be
Subdirectory placed in this subdirectory.
For a further explanation of these fields, see "What is a Release Template?" on page
209.
A Releases Using Above Template area, containing a table of releases created
using the selected template. It displays the following for each release:
Field Description
Product Id The product to which the release belongs.
Release Id The ID of the release that uses this template.
Creation Date The date the release was created.
Field Description
Name The name that identifies the item type group.
Button Function
Allows you to add an item type to the group.
Field Description
A check box to select the item type(s) to be
Check Box deleted from the group.
Name The name of the item type.
A Release Templates Using Above Item Types Group section displaying the
following fields for each release in which the item type group has been used:
Field Description
The name of the release template that uses the
Template ID item type group.
The user ID of the user who created the
Created By template.
Creation Date The date the template was created
1 From the Baseline and Release Templates main window, select Baseline Templates
from the list in the navigation area.
The New Baseline Template dialog box or Copy Baseline Template dialog box appears.
Once the template has been created, you can subsequently define the selection criteria,
as described in How to Define the Selection Criteria for a Baseline or Release Template on
page 220.
1 From the Baseline and Release Templates main window, select Baseline Templates
from the list in the navigation area.
The New Release Template dialog box or Copy Release Template dialog box appears.
Once the template has been created, you can subsequently define the selection criteria,
as described in "How to Define the Selection Criteria for a Baseline or Release Template"
on page 220.
1 From the Baseline and Release Templates main window, select Item Type Groups from
the list in the navigation area.
2 Click the button in the main window. The New Item Type Group dialog box
appears.
3 Enter a name for the item type group in the Item Type Group Name field.
4 Select the first item type to include in the group from the Item Type list. You can
include additional item types later.
1 In the Baseline and Release Templates main window, select the object that you want
to delete in the navigation area or the content area.
1 From the Baseline and Release Templates main window, select Item Type Groups from
the list in the navigation area.
2 Select the item type group in the navigation area. This will display the details in the
content area.
1 From the Baseline and Release Templates main window, select the baseline or release
template for which you want to define the selection criteria in the navigation area.
This will display the template details in the content area.
6 Click OK.
In this Chapter
Constraints You must be the Tool Manager to modify default rules for Dimensions or IDEs. You must
be the Product Manager to modify rules for a specific IDE project.
Starting with Dimensions 7.0, default upload rules are automatically included when you
create a database. The default rules apply to Dimensions clients and each supported IDE.
You can modify the default rules, as well as create and modify rules for specific IDE
projects and Dimensions CM products.
For more Upload rules determine the attributes of new items that are created in Dimensions. See
information About Attributes on page 42 for more information on how attributes work.
For example, a team lead wants to have a file to keep notes on the. project The file the
notes are kept in is a MS Word document and the item type is PN, with a lifecycle of Open
and Closed. Other MS Word and .txt documents in the project all have the same item
type, DOC, and so the same lifecycle, Draft, Review, and Approved.
When adding a single item to a project or stream the item type can be changed.
When adding multiple files of the same data type but different item type, this can be
achieved by using filename pattern matching:
Make sure the project note files contain the same string in their names, for example,
are all named <project>_pn.doc.
Update the upload rules for the client and product so that the filename pattern,
_pn.doc, is assigned the PN item type.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
1 From the Upload Rules main window, select an upload project in the navigation area:
Dimensions Clients | Default Project for the Dimensions default rule set.
Dimensions Clients | product name for the rule set for a specific product.
IDE Name | Default Project for an IDE default rule set.
IDE Name | Project Name for an IDE project rule set.
2 In the General section in the content area, click the Copy button: . The Copy
Inclusions/Exclusions dialog box appears.
3 From the Source project list, select the project whose rules you want to copy.
4 Click OK.
1 From the Upload Rules main window, select one of the following from the navigation
pane:
Dimensions Clients | Default Project to add the file inclusion to the Dimensions
default rule set.
Dimensions Clients | product name to add the file inclusion to the rule set for a
specific product.
IDE Name | Default Project to add the file inclusion to an IDE default rule set.
IDE Name | Project Name to add the file inclusion to an IDE project rule set.
2 From the Include section, select an existing inclusion if you want the new inclusion to
be added above it in the list. Otherwise, the new inclusion will appear at the bottom of
the list.
3 Click the New button: . The New Upload Inclusion dialog box appears.
4 Enter the file name pattern for the files you want to include in the File Name Pattern
Match field.
5 Enter the Dimensions data format to map to the file name pattern in the Data
Format field.
7 Click OK.
NOTE Where there is a conflict, the list of files to exclude supersedes the list of files to
include.
1 From the Upload Rules main window, select one of the following from the navigation
pane:
Dimensions Clients | Default Project to add a file exclusion to the Dimensions
default rule set.
Dimensions Clients | product name to add a file exclusion to the rule set for a
specific product.
IDE Name | Default Project to add a file exclusion to an IDE default rule set.
IDE Name | Project Name to add a file exclusion to an IDE project rule set.
2 From the Exclude section, click the New button: . The New Upload Exclusion dialog
box appears.
3 Enter the file name pattern of the files you want to exclude from Dimensions in the
File Name Pattern Match field.
4 Click OK.
1 From the Upload Rules main window, select one of the following from the navigation
pane:
Dimensions Clients | Default Project to add an inclusion or exclusion to the
Dimensions default rule set.
Dimensions Clients | product name to add an inclusion or exclusion to the rule
set for a specific product.
IDE Name | Default Project to edit or delete an inclusion or exclusion from an
IDE default rule set.
IDE Name | Project Name to edit or delete an inclusion or exclusion from an IDE
project rule set.
2 Select the file inclusion from the Include section that you want to edit or delete, or
select the file exclusion from the Exclude section.
You can select more than one inclusion or exclusion to delete.
In this Chapter
There are three types of preservation rule that determine the type of item revision that
can be created for a build output:
Normal: An output file from a build is stored as a normal item revision with the file
stored in a Dimensions item library.
External: An output file from a build (such as a listing) that is stored outside a build
area. It is represented as an item revision but the item file is not stored in a
Dimensions item library. You can, however, get or check out the item revision, in
which case the external file is copied to your work area.
Placeholder: An output file from a build that can be inside or outside a build area. It
is represented as an item revision but the item file is not stored in a Dimensions item
library and you cannot get or check out the item file.
Note that external and placeholder item revisions do not get promoted from one build
area to another.
When you define a preservation policy, you specify the default preservation rule for all
item types for build outputs by choosing one of these three options. You can then
optionally add one or more preservation rules to override the default one for any specific
item types that you want to be treated differently.
Once defined, you can associate different preservation policies with different stages of a
build project. If you do not specify a preservation policy for a build stage the default is to
preserve all build outputs as normal Dimensions items.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Define a new preservation policy using the New Preservation
Policy dialog box.
Create a preservation policy by copying the details of an
existing preservation policy.
Delete the selected preservation policy.
When you select a preserving policy icon: in the navigation area, you can do the
following in the content area:
Add: edit: or delete: a preservation rule in the Preservation Rules
area.
Add: or delete: stages for a project in the Used By area.
Set up one or more preservation rules within the preservation policy for specific item
types that override the default rule. See "How to Add, Edit or Delete Preservation
Rules" on page 233.
Associate this preservation policy with one or more stages for one or more projects.
See "How to Add or Delete Project Stages" on page 234
1 In the Build Administration main window, click the Preservation Policies tab.
2 In the status area, select the product to which the preservation policy is to belong.
Copy a preservation policy when you want to create a new preservation policy based on
an existing policy and its rules.
Delete a preservation policy when it is not required or has been created in error.
Constraints When you edit a preservation policy, you cannot change its name.
You can only delete a project whose status is SUSPENDED.
1 Make sure the product to which the preservation policy belongs is selected in the
status area
2 In the Build Administration main window, click the Preservation Policies tab and select
the preservation policy in the navigation area.
1 In the Build Administration main window, click the Preservation Policies tab and select
the preservation policy whose rules you want to change in the navigation area.
2 Click Edit:
2 Click Delete:
1 In the Preservation Policies main window, click the Preservation Policies tab and select
the preservation policy whose project stages you want to change in the navigation
area.
3 Select the stage(s) for this project for which you want
the preservation policy to apply.
Delete a stage for a 1 Select the Project and stage you want to delete.
project
2 Click Delete:
In this Chapter
If a data format is not assigned to a particular item type, you can use any format when
you create an item, including formats that have not been defined. If a data format is not
registered, then it is assumed by Dimensions to be of type BINARY. Binary files do not
undergo end of line translation when moving from one operating system to another.
Therefore it is important to plan and manage this information.
From the Data Format and MIME Types main window you can:
List the data formats and Multipurpose Internet Mail Extension (MIME) types currently
registered in the base database.
Filter the list of data formats and MIME types according to user-defined criteria. See
"How to Filter Data Formats" on page 241.
Create (register) a new data format and MIME type. See "How to Create a New Data
Format" on page 241.
Edit an existing data format and MIME type. See "How to Edit a Data Format" on page
242.
Delete a data format and MIME type. See "How to Delete a Data Format" on page
242.
Assign item types to a data format and list the current assignments, see "About
Assigning Item or Request Types" on page 242.
PRIVILEGES Manage File Format Definition
Constraints Only the Tool Manager can define data formats and MIME types, and only a Product
Manager can assign them to item types.
Windows.
These classes are hard coded into Dimensions CM and cannot be modified. At present, all
items that do not have a class of "ASCII" will be transferred between Dimensions CM
clients and servers in binary mode.
MIME types comprise several broad categories, with each category also having subtypes
(see About the MIME Subtypes for full details) defined by using a separator. Common
examples of MIME types are "text/plain", "text/html", "application/msword" and
"application/pdf".
To find out current IANA media types, visit the web site
http://www.iana.org/assignments/media-types/
Type Subtypes
text enriched plain html
richtext sgml tab-separated-values
vnd.fmi.flexstor vnd.latex-z
multipart alternative appledouble byteranges
digest encrypted form-data
Type Subtypes
header-set mixed parallel
related report signed
voice-message
message external-body http news
partial rfc822
application activemessage andrew-inset applefile
atomicmail cals-1840 commonground
cybercash dca-rft dec-dx
eshop hyperstudio iges
mac-binhex40 macwriteii mathematica
msword news-message-id news-transmission
octet-stream oda pdf
pgp-encrypted pgp-keys pgp-signature
postscript prs.alvestrand. prs.nprend
titrax-sheet
remote-printing riscos rtf
set-payment set-payment-initiation set-registration
set-registration- sgml sgml-open-catalog
initiation
slate vemmi vnd.
$commerce_
battelle
vnd.businessobjects vnd.ecdis-update vnd.enliven
vnd.fdf vnd.FloGraphIt vnd.
framemaker
vnd.hp-HPGL vnd.hp-PCL vnd.hp-PCLXL
vnd.ibm vnd.intercon vnd.intertrust.
.MiniPay .formnet digibox
vnd.intertrust vnd.japannet- vnd.japannet-
.nncp directory-service jpnstore-wakeup
vnd.japannet- vnd.japannet- vnd.japannet-
payment-wakeup registration registration-wakeup
vnd.japannet- vnd.japannet- vnd.japannet-
setstore-wakeup verification verification-wakeup
vnd.koan vnd.lotus-1-2-3 vnd.lotus-approach
vnd.lotus-freelance vnd.lotus-organizer vnd.lotus-screencam
vnd. vnd.meridian- vnd.mif
lotus-wordpro slingshot
vnd.ms-artgalry vnd.ms-asf vnd.ms-excel
vnd.ms-powerpoint vnd.ms-project vnd.ms-tnef
Type Subtypes
vnd.ms-works vnd.musician vnd.music-niff
vnd.noblenet- vnd.noblenet-sealer vnd.noblenet-web
directory
vnd.osa. vnd.powerbuilder6 vnd.powerbuilder6-s
netdeploy
vnd.rapid vnd.seemail vnd.shana.
informed.
formdata
vnd.shana. vnd.shana. vnd.shana.
informed. informed. informed.
formtemplate interchange package
vnd. vnd.svd vnd.truedoc
street-stream
vnd.webturbo vnd.xara wita
wordperfect5.1 x400-bp zip
image cgm g3fax gif
ief jpeg naplps
png tiff vnd.dwg
vnd.dxf vnd.fpx vnd.net-fpx
vnd.svf
audio 32kadpcm basic vnd.qcelp
video mpeg quicktime vnd.motorola.
video
vnd.motorola vnd.vivo
.videop
model iges mesh vrml
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Description
Create a new data format using the new Data Format dialog box.
Edit a data format using the Edit Data Format dialog box.
Delete a data format.
1 In the Data Format and MIME Types main window, click the Filter link:
2 Set up your filtering criteria in the Data Format Filter dialog box.
3 Click OK. The data formats listed in the main window will be filtered on the criteria
entered.
1 In the Data Format and MIME Types main window, click the Filter link: The
Data Format Filter dialog box appears.
2 Click the Reset Filter button. This will clear all the fields in the dialog box.
3 Click OK. The main window will now contain all the data formats in the base database.
1 From the Data Format and Mime Types main window, click the New button: The
New Data Format dialog box appears.
2 Enter the name of the new format in the Data Format field.
3 Select the class of the item type from the Class list.
4 Select the Compression level. This is the level of compression to be used when
getting item revisions that are assigned this data format. Choose between:
No Compression.
Fast Compression —This performs the compression quickly and using less
memory but is the least compressed.
Normal Compression—a normal degree of compression. This is a happy medium
between Fast and Best.
Best Compression—This is the slowest but gives the best compression.
5 data format.
8 Click OK.
1 From the Data Format and Mime Types main window, click the name link of the data
format you want to edit, or select it and click the Edit button:
2 Update the fields in the Edit Data Format dialog box as necessary. For details of these
fields, see "How to Create a New Data Format" on page 241.
3 Click the Used By tab if you want to assign or unassign item types. See How to Assign
Item or Request Types to a Data Format on page 243 for details.
4 Click OK.
1 In the Data Format and Mime Types main window, select the data format(s) you want
to delete.
2 Click the Delete button: You will be prompted with a dialog box asking you to
confirm the deletion.
3 Click OK.
Assign Data formats to request types to determine how they are displayed in
Dimensions CM. Once assigned, the format and MIME type are used by the
Dimensions CM client applications (web client, desktop client, and IDE) to correctly
choose an application/viewer to display the request.
1 From the Data Format and Mime Types main window, click the name link of the data
format you want to edit, or select it and click the Edit button: The Edit Data
Format dialog box appears showing the General tab.
5 Select the product that owns the item or request type you want to assign from the
Product Id list.
6 Select the item or request type you want to assign from the Item/Request Type
Name list.
7 Click OK. You will be returned to the Edit Data Format dialog box.
8 Repeat steps 3, 4, and 5 for each item or request type you want to assign.
1 From the Data Format and Mime Types main window, click the name link of the data
format you want to edit, or select it and click the Edit button: The Edit data
Format dialog box appears showing the General tab.
3 Select the Item or request type(s) you want to unassign from the data format.
4 Click the Unassign button: The Unassign dialog box appears asking you if you
are sure you want to unassign the item or request type.
5 Click Yes. You will be returned to the Edit Data Format dialog box.
6 Repeat steps 3, 4, and 5 for each item or request type you want to unassign.
In this Chapter
Constraints This function can only be run by the ADMIN group or the Product Manager.
You cannot delete a version branch name if it is currently used to label any item
pedigree trees.
An option to delete a currently used version branch name is available using the
Dimensions Remove Version Branch (RMVB) command with the /FORCE qualifier.
Please refer to the Command-Line Reference Guide for further details.
For more If you have installed the separately licensed Dimensions CM Replicator, refer to the
information Dimensions CM Administrator's Guide for branch details specific to Replicator.
In the case of a stream, a single branch name is assigned that is used for all new item
revisions in that stream. When you create a new stream, you can either assign an existing
branch name or create a new one as a part of the Create Stream process.
The use of version branch names within a project is optional, but a stream must have a
branch name.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Define a new version branch name using the New Version
Branch dialog box.
When you select the Branches icon: in the navigation area, you can do the
following in the content area:
Select a branch name to edit or delete it. Click to select or deselect all of the
version names in the list.
Print the list of branch names by clicking
Save the list of branch names as comma-separated values by clicking
Sort the branch names by clicking the column headings.
1 From the Version Branch Names window, click the New button:
The New Version Branch dialog box appears.
2 Enter a name for the branch in the Version Branch Name field.
Constraint You cannot delete a version branch name if it is currently used to label any item pedigree
trees.
In this Chapter
About Areas
Areas are locations that are defined in order to contain item files for Dimensions CM
project/streams when certain item operations are performed. You define a network node
and folder for the area so that the files are held under that "root" folder in the same
hierarchical folder structure as the items in the project/stream. There are three types of
area:
Work Area: An area that is defined for one or more users or groups, so that their
Dimensions CM file operations such as check in, check out, and so on, automatically
use this area to contain the item files for those operations.
Deployment Area: An area that is defined to contain files whose items have reached
a particular stage in the lifecycle for a project. This means that item files are moved to
that area when the item revisions are deployed to the corresponding stage in the
Global Stage Lifecycle.
Deployment areas can also have a Filter specified. A filter is a template file containing
a set of rules that determine which files from the project/stream are held in the file
area. You can specify that only the items matching a certain filename pattern, or that
belong to a certain design part, are transferred to that area.
You can also specify Transfer Scripts for a deployment area. These are scripts that
are performed:
• Before files are transferred to the area.
• After files have been transferred to the area.
• On Fail. The script is performed if, for any reason, the transfer of the files has
failed to complete successfully.
Library Cache Area: An area that is defined in order to contain copies of files whose
items are located on a database on a remote server. The purpose is to improve
Dimensions CM file get performance. When a user obtains a copy of a file using an
operation such as get or check out, Dimensions CM first looks in the library cache area
to see whether that file is already there and uses that copy instead of transferring the
file from the item library. This makes the processing more efficient if, for example the
files are being transferred via the network from another country, and a number of
users are accessing them. (The administrator could also set up a batch process to
populate the library cache area with the latest file versions overnight, when users are
not accessing it.)
The use of library cache areas is supported for the following clients:
• Desktop client
• DMCLI
• DMPMCLI
• PowerBuilder
• Eclipse plug-in
• .NET integration
• Web client
NOTE A library cache area can be used in the web client provided that the user sets
the work area to a work area that has been defined in Dimensions as opposed to a
folder location on their local machine. A library cache area is assigned for your user
for a given project/stream using the Project/Stream Properties dialog box in the web
client or desktop client. If the working location is not set to a Dimensions-defined
work area, the library cache area will not be used for item file operations in the web
client although it will be used in the desktop client.
Once you have defined a file area you relate it to one or more projects/streams so that it
is used to contain item files for those projects/streams
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Create a new area using one of the following:
New Work Area dialog box
New Deployment Area dialog box
New Library Cache Area dialog box.
Delete the selected area(s).
Defining Areas
1 From the Areas tab, click the New button: on the toolbar, and select an option
for the type of area you want to create from the list; Work Area, Deployment Area,
or Library Cache Area. The New Area dialog box appears.
2 Enter a name for the area in the Name field. Optionally enter a Description.
3 Select a Network node from the list and enter a Directory to be used for the area
on that node or use the browse button to select it.
NOTE This is a logical network node that needs to have been defined in the
Administration Console Netwoek Administration. See the Administrator's Guide for
details.
NOTE You cannot assign the same location (the same network node and directory) to
more than one area. An error will occur if this location has already been assigned.
4 Enter the Node user ID and Node password to use for the operating system on the
network node. You can also enter a credential set, in which case the Node password
is not required. For details on credential sets, see the Administrator's Guide.
NOTE This user ID and password need to have been registered using the dmpasswd
utility. See the Administrator's Guide for details.
5 If you have selected Deployment Area, select a Stage ID to be associated with this
area from the list.
6 If you have selected Deployment Area, optionally enter the name of a template
containing filtering criteria for the items to be included in this area.
7 Enter the Dimensions CM user ID for the Area owner, or accept your current user as
the default.
8 If you have selected Deployment Area, optionally enter the name(s) of any files
containing Transfer Scripts you want to be performed in relation to the transfer of
files to the area, Pre-event, Post-event, or Fail-event.
For details of configuring and using these scripts, see "Deployment Area Scripts" in
the Developer’s Reference.
9 If you have selected Deployment Area or Library Cache Area, and you want to
exclude the area from all transfer operations at the present time, select Is this area
currently offline?
10 If you have selected Work Area, include the users/groups you want to assign to the
area:
To add a user/group, select the name in the Available Users list, and click the >>
link to move it to the Assigned Users list
To remove a user/group, select the name in the Assigned Users list, and click the
<< link.
To edit an area:
PRIVILEGES
Update Work Areas for work areas
Update Deployment Areas for deployment areas
Update Library Cache Areas for library cache areas
2 In the content area, in the General section, click the Edit button: . The Edit Work
Area, Edit Deployment Area, or Edit Library Cache Area dialog box appears.
To delete an area:
PRIVILEGES
Delete Work Areas for work areas
Delete Deployment Areas for deployment areas
Delete Library Cache Areas for library cache areas
1 On the Area Definitions tab, select the top-level node: or an area type node: in
the navigation area.
2 Select the area in the navigation area and Click the Delete button: .
1 On the Area Definitions tab, in the navigation area, select a deployment area.
2 In the navigation area, in the Projects section, click the Add button: . The
Assign Area to Project dialog box appears.
4 If you want to use a folder that is offset, or located in another folder relative to the
Area's directory, enter the relative path to be used in File path relative to Area
Directory.
5 Select Deploy by default if you want files to automatically be deployed to this area
when the item revisions are promoted or demoted to this stage.
6 Select an Audit filter from the list, or leave this as default to use the default filter for
the area.
7 Enter a Sequence order if you want deployments to this area to occur in a particular
order relative to other deployment areas when there is more that one deployment
area for this project/stream. See the Deployment Guide for the rules for deployment
sequences.
8 If you want the area to be populated with item files as soon as you relate the project/
stream, select Populate Area with Project contents.
1 On the Area Definitions tab, in the navigation area, select a deployment area:
2 In the navigation area, in the Projects section, select a project and click the
button. The Edit Assignment dialog box appears.
3 If you want to use a folder that is offset, or located in another folder relative to the
Area's directory, enter the relative path to be used in File path relative to Area
Directory.
4 If you want the area to be populated with item files as soon as you relate the project/
stream, select Populate Area with Project contents.
5 If you want the item files to remain where they are if the relative path changes, select
Do not delete files from old relative path if relative path changes.
1 On the Area Definitions tab, in the navigation area, select a deployment area:
2 In the navigation area, in the Projects section, select a project/stream and click the
button. The Unassign Project from Area dialog box appears.
areas for a project can be associated with these stages so that item files are copied to
those areas when they are deployed to the corresponding stage.
Button Function
Allows you to delete a stage. For details, see How to Delete a Stage.
Allows you to rename a stage. For details, see How to Modify a Stage.
Button Function
Allows you to edit the description of a stage.
Allows you to import an image file using the Import Lifecycle Image dialog
box.
Allows you to export an image file associated with a lifecycle to your work
area.
Allows you to delete an associated image for the lifecycle.
A filter bar that has filters allowing you to control what appears in the Transitions
area:
Role: When you select a role from the list, all the stages available to that role
become highlighted. When you select a stage and a role, only those transitions in
or out of that stage that are assigned to the selected role are displayed in the
Transitions area.
Stage: When you select a stage from the list, that stage becomes highlighted in
the lifecycle model. It is an alternative to selecting the stage in the lifecycle model.
When you select a stage in the lifecycle model this filter updates to reflect your
selection.
You can select a stage by clicking it or by choosing it in the Stage filter. The arrows
representing the possible transitions into that stage become highlighted in light blue, and
the transitions out of it become highlighted in dark blue. When a stage is selected, the
Transitions area only shows the possible transitions to and from that stage, whereas when
no stage is selected all the transitions for the lifecycle are shown.
You can create a new transition by clicking in one stage and dragging the mouse pointer
into another stage. This displays New Transition dialog box.
To delete a stage:
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
3 Click the Delete button: You will be prompted with a dialog box asking you to
confirm the deletion.
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
2 Select the stage whose description you want to change in the Lifecycle Model.
1 On the Area Definitions tab, on the toolbar, click the Edit Global Stage Lifecycle
button: The Edit Global State Lifecycle dialog box appears.
2 Click the button in the toolbar. The Import Lifecycle Image appears.
3 Enter or browse to the filename and path of the image you want to import in the
Filename field.
1 On the Area Definitions tab, on the toolbar, click the Edit Global Stage Lifecycle
button: The Edit Global State Lifecycle dialog box appears.
2 Click the button in the toolbar. The image will be displayed in a new browser
window.
3 Use the Save As function of the browser to save the image to your work area.
1 On the Area Definitions tab, on the toolbar, click the Edit Global Stage Lifecycle
button: The Edit Global State Lifecycle dialog box appears.
2 Click the button in the toolbar. A dialog box is displayed asking you if you are
sure you want to delete the image.
Transitions Area
The Transitions area of the Edit Global Stage Lifecycle dialog box displays the possible
transitions in or out of the stage you have currently selected in the Lifecycle Model. If no
stage has been selected, it displays all transactions for all stages of the lifecycle.
It consists of:
A toolbar
A table of transitions and roles.
Button Function
Allows you to add a new transition using the New Transition dialog
box.
Allows you to edit a transition using the Edit Transition Lifecycle
dialog box.
Allows you to delete one or more transitions.
The table of transitions and roles contains a row for each combination of transition with
each role that is authorized to promote item revisions through this stage. If a role is
selected in the role filter, only that role will appear in the list.
Next to each role, there is an icon indicating whether the role is optional or pending.
Icon Meaning
O Optional. This means that promoting an object to the transition's from stage
does not require there to be a user holding that role.
If the role is not optional, the promoting will be disallowed if there are no
users holding that role.
P Pending. The object will appear in the user's inbox and the user will receive
e-mail notification when the item is promoted to the from stage for the
transition.
If the role is not pending, it will not appear in the user's inbox and the user
will not receive e-mail notification, but the user will still be able to perform
the promotion.
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
3 Select the stages in the transition in the From Stage and To Stage fields. To create
new stages, enter them in the fields.
NOTE An existing transition can be split by creating a transition that inserts a new
stage within the lifecycle path. If this is the case, the existing transition will be
adjusted, but you will be prompted with a message asking you to confirm this before
the new transition is created.
4 Select the roles for the transition from the Roles list and specify whether you want the
roles to be optional and/or pending.
5 If you want the dialog box to remain open, select the Keep Open check box.
Constraints The role titles defined in each lifecycle transition must have been previously defined
(except for $ORIGINATOR). See "How to Add Roles" on page 96 for details.
To edit a transition:
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
2 Select the stage for the transition you want to edit in the Lifecycle Model.
3 Select the transition in the Transitions area and click the Edit Transition button:
To delete transitions:
1 On the Area Definitions tab, in the navigation area, click the Edit Global Stage
Lifecycle button: The Edit Global State Lifecycle dialog box appears.
2 Select the stage for the transition you want to delete in the Lifecycle Model.
3 Select the transition(s) you want to delete in the Transitions area and click the Delete
Transition button: You will be prompted with a dialog box asking you to confirm
the deletion.
4 Click OK to delete the transition(s). Any off-normal stages that no longer have any
transitions to or from them will also be removed.
You can define a series of filename matching patterns and specify that files matching
those patterns are either to be included in the filter, or to be excluded from the filter.
The management of Area Filters within the Administration Console enables you to:
List (query) existing area filters in the Dimensions CM base database.
Create an area filter in order to add a series of file selection criteria for that filter.
Add, edit, or delete a file selection criteria for the items to be excluded in a
deployment.
Add, edit, or delete a file selection criteria for the items to be excluded from a
deployment.
Create a new area filter by copying the details of an existing one.
Delete an area filter.
You associate an area filter with a deployment or library cache area using the
Administration Console Area Definitions option. See "Defining Areas" on page 254.
1 If the area has no area filter defined, the item revision is transferred into the area.
2 Otherwise, if the item revision matches an exclusion rule, the revision is not
transferred into the area.
3 Otherwise, if there are no inclusion rules, the revision is transferred into the area.
4 Otherwise, if the item revision matches an inclusion rule, the revision is transferred
into the area.
Examples:
*.java matches .java, x.java and Foo.java, but not Foo.xml
?.java matches Q.java, x.java, but not .java or abc.java
Matching is done per-directory. First the first directory in the pattern is matched against
the first directory in the path to match, then the second directory is matched, and so on.
For example, when we have the pattern /?abc/*/*.java and the path /xabc/foobar/
test.java, the first ?abc is matched with xabc, then * is matched with foobar, and
finally *.java is matched with test.java. They all match, so the path matches the
pattern.
There is an extra feature, which makes it possible to match multiple directory levels. This
can be used to match a complete directory tree, or a file anywhere in the directory tree.
To do this, ** is used as the name of a directory. When ** is used, it matches zero or
more directories. For example: /test/** matches all files/directories under /test/,
such as /test/x.java, or /test/foo/bar/xyz.html, but not /xyz.xml.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Create a new file filter using the New Area Filter dialog box
Field Description
A check box to select or deselect the area filter(s) for the
Check Box operations performed by the toolbar buttons.
Filter ID The name that identifies the area filter.
Creation Date The date the filter was created.
Originator The user ID of the user who created the filter.
The content area of the Area Filters tab with a specific area filter selected consists of:
A General section displaying the following fields:
Field Description
Filter ID The name that identifies the area filter.
Creation Date The date the filter was created.
Created By The user ID of the user who created the filter.
Button Function
Allows you to add a selection criterion using the New Selection
Criterion dialog box.
Allows you to edit the selected selection criterion using the Edit
Selection Criterion dialog box.
Allows you to delete a selected selection criterion.
Button Function
Allows you to add a selection criterion using the New Selection
Criterion dialog box.
Allows you to edit the selected selection criterion using the Edit
Selection Criterion dialog box.
Allows you to delete a selected selection criterion.
1 From the Area Definitions main window, select the Area Filters tab.
The New Area Filter dialog box or Copy Area Filter dialog box appears.
Once the template has been created, you can subsequently define the selection criteria,
as described in How to Define the Selection Criteria for an Area Filter on page 269.
1 From the Area Definitions main window, select the Area Filters tab and select the
area filter for which you want to define the selection criteria in the navigation area.
This will display the template details in the content area.
3 If required, enter the file path pattern to use for matching the files that you want to
exclude/include in the File Path Pattern field. For details, see "About File Pattern
Matching" on page 266.
4 If you want to only exclude/include items belonging to a particular design part, enter
the design part specification in the Design Part field, or use the browse button
to select it.
5 If you want to include the child design parts belonging to the selected Design Part,
select Recurse Part Structure.
6 If required, from the Data Format list, select a data format for the items you want to
exclude/include.
7 If required, from the Item Type list, select an item type for the items you want to
exclude/include.
8 Click OK.
In this Chapter
At the present release, the only type of external request provider supported is Serena®
SBM. This external request provider is supported in the Visual Studio and Eclipse
Integrations, and the desktop client.
An IDM tool instance is a distinctly named definition for a particular installation of of the
IDM Tool, in this case Serena SBM. The instance is identified by its name and specifies
the URL of the Web Interface, the URL for Web Services and a SBM Solution from which
issues will be available for use.
The use of an external IDM tool is optional, and the default is to use Serena Dimensions
CM requests.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Set an IDM tool instance as the default.
Button Function
Allows you to add an IDM tool instance using the New IDM Tool
Instance dialog box.
Allows you to edit a selected IDM tool instance using the Edit IDM Tool
Instance dialog box.
Allows you to delete a selected IDM tool instance.
When you select an IDM tool instance in the navigation area, you can view the details, or
edit them using the button.
1 Create an IDM tool Instance. See "How to Create an IDM Tool Instance" on page 274.
If you change the default IDM tool instance or provider, user’s working lists and project
default requests will be cleared.
When changing the default IDM tool instance or provider, you should make sure that no
clients are connected to the server when the change is being made.
PRIVILEGES Manage IDM Tools
3 Click OK.
If you have changed the default IDM instance then you will see the following warning
message:
"Warning: if the default IDM tool instance is changed the working lists and project
default requests of ALL users will be erased."
Click OK again to change the default IDM tool instance or press Cancel.
1 From the IDM Tools Configuration window, click the New button:
The New IDM Tool Instance dialog box appears.
4 For Web GUI URL, enter the URL of the GUI for the Serena SBM service. For
example:
http://<hostname>/tmtrack/tmtrack.dll?
where hostname is the host name of the SBM server.
5 For Web Services URL, enter the URL of the Web services application for the Serena
SBM service. For example:
http://<hostname>/gsoap/gsoap_ssl.dll?aewebservices71
where hostname is the host name of the SBM server.
6 For Application, enter the name of the application in Serena SBM that contains the
issues to be provided, for example:
ISSUE_DEFECT_MANAGEMENT
If you change the default IDM tool instance, user’s working lists and project default
requests will be cleared.
When changing the default IDM tool instance, you should make sure that no clients are
connected to the server when the change is being made.
PRIVILEGES Manage IDM Tools
Constraint You cannot delete an IDM tool instance if it is currently used to label any item pedigree
trees.
1 From the IDM Tools Configuration window, expand the tree in the navigation area and
select the node: for the IDM tool instance.
4 If required, select the Attributes tab and edit the required fields:
For Web GUI URL, edit the URL of the GUI for the Serena IDM service.
For Web Services URL, edit the URL of the Web services application for the
Serena IDM service.
For Solution, edit the name of the solution in Serena IDM that contains the issues
to be provided.
5 Click OK.
1 From the IDM Tools Configuration window, expand the tree in the navigation area and
select the node: for the IDM tool type.
2 In the content area under the IDM Tool Instances tab, select the IDM tool instance.
3 Click the button and click Yes to confirm that you want to delete the instance.
Note that at present, the only such option available is Project/Stream Options.
PRIVILEGES Manage Database Options
For details of the differences between streams and projects and the operations that can
be used with them, see the User's Guide.
For the location of the parts of the Administration Console main window, see "The Specific
Function Window" on page 78
Button Function
Edit a database option.
1 From the Database Options window, expand the tree in the navigation area and select
the node: for Project/Stream Options.
4 Click OK.
In this Chapter
Introduction 280
Supported OS Platforms 280
Dimensions Components 280
Using the Scripting Interface Shell 285
Using the Object Model 288
Web-Based API Documentation 294
Example Java Scripts 295
Introduction
Dimensions is a rich environment available on a wide range of platforms. Until recently
Dimensions functionality could only be accessed via the command-line or from the DTK/
trigger API. Both of these interfaces exposed only a subset of the existing functionality.
The scripting interface overcomes this limitation by providing a set of Java classes that
expose Dimensions components via a simple and consistent object model. This object
model is primarily intended for use by scripting languages hosted in the JVM (Java Virtual
Machine), such as JavaScript™, Python, Tcl and others. The current scripting interface
includes Rhino, an open-source Java-based JavaScript interpreter from www.mozilla.org,
and sample scripts that demonstrate the functionality that is available.
This chapter is intended for installers, administrators and users of Dimensions on UNIX
and Windows platforms.
Supported OS Platforms
All platforms certified for use with a Dimensions 12.2.1.x server are supported, provided
that Java™ 2 Runtime Environment Standard Edition, version 1.3.x or higher, is available
on that platform.
Dimensions Components
The scripting interface includes support for the following Dimensions components.
Supported Dimensions
Component Supported Operations
Attribute Blocks List existing attribute block definitions.
Create a new attribute block definition for an object
type.
Update an attribute block definition.
Delete an attribute block definition.
List attributes assigned to an attribute block's columns.
Assign attributes to, or deassign attributes from, an
attribute block's column.
Attribute Definition List existing attribute definitions.
Create a new attribute definition for an object type.
Update an attribute definition.
Deassign an attribute definition from an object type;
and delete it (optional).
List types assigned to an attribute definition.
(Sheet 1 of 6)
Supported Dimensions
Component Supported Operations
Base Database Log in to Dimensions.
Log out from Dimensions.
Authenticate a user in order to perform tertiary node
access to items located on a remote node.
Baseline Template List existing baseline templates.
Create a baseline template.
Delete a baseline template.
List baselines using a baseline template.
Copy baseline template rule definitions between
baseline templates.
Baseline Template Rule List existing baseline template rules.
Create a baseline template rule.
Delete a baseline template rule.
Update a baseline template rule.
Build Areas List existing build areas.
Create new build area definition.
Update a build area definition.
Delete a build area definition.
Build Projects List existing build projects.
Create new build project definition.
Update a build project definition.
Delete a build project definition.
List projects assigned to a build project.
Build Stages List existing build stages.
List lifecycle states using a build stage.
List build areas defined for a build stage.
Request Relationship Type List defined request relationship types.
Create a relationship type.
Delete a relationship type.
Update a relationship type.
Request Type CM Rules Define and/or update change management (CM) rules.
File Format List existing formats.
Create a new format.
Update format attributes.
Delete a format.
(Sheet 2 of 6)
Supported Dimensions
Component Supported Operations
Item, Request, and Baseline List existing item and baseline replication
Replication Configurations configurations.
Create new replication configuration.
Update a replication configuration definition.
Delete a replication configuration definition.
Item To Item Relationship Type List item to item relationship types.
Create an item to item relationship type.
Delete an item to item relationship type.
Update an item to item relationship type.
Item Type CM Rules Define and/or update change management rules.
Item Type Group List defined item type groups.
Assign an item type to an item type group.
Deassign an item type from an item group.
List types assigned to an item type group.
List release templates assigned to an item group
Item/Request Browse Templates List existing browse template revisions.
Create a template revision.
Delete a template revision.
Import a file into a template revision.
Export a file from a template revision.
Lifecycle List existing lifecycles.
Create a new lifecycle.
Update lifecycle attributes.
Delete a lifecycle.
List the types using a lifecycle.
List assigned image revisions.
Assign, or deassign, default image revisions to a
lifecycle.
Lifecycle and Browse Template List existing assignments for a request type.
Assignments at Design Part Level
Create a new assignment.
Delete an assignment.
Lifecycle Image Revision List lifecycle image revisions assigned to a lifecycle.
Create an image revision.
Delete an image revision.
Import a file into an image revision.
Export a file from an image revision
(Sheet 3 of 6)
Supported Dimensions
Component Supported Operations
Lifecycle State Transition List a lifecycle's state transitions.
Create a new transition.
Delete a transition.
Add roles to, and remove roles from, the list of roles
authorized to perform a transition.
Rename a state.
Delete a normal state.
Object Type For all object types:
List existing object types.
Create an object type.
Update an object type definition.
Delete an object type definition.
Assign, or deassign, a lifecycle.
Define attributes and attribute blocks.
Copy attributes between object types.
For item types:
List assigned file formats.
Assign, or deassign, a file format.
Assign, or deassign, a default template revision to an
item/request object type.
Define, update or delete item libraries and/or the default
item library.
Define change management rules.
For request types:
Assign, or deassign, a default template revision to an
item or request object type.
Define change management rules.
Priming Relationship List priming relationships defined for a request type.
Create a priming relationship.
Delete a priming relationship.
List attribute mappings.
Add and/or delete attribute mappings.
Product List existing products.
Create a new product.
Update a product definition.
Delete a product.
(Sheet 4 of 6)
Supported Dimensions
Component Supported Operations
Projects List existing projects.
Create new project definition.
Update a project definition.
Delete a project definition.
List build areas defined for a project.
Relationship Names List relationship names defined in a base database.
Create a relationship name.
Delete a relationship name.
Update a relationship name.
List item to item relationship types using a relationship
name.
Release Template List existing release templates.
Create a release template.
Delete a release template.
List releases using a release template.
Copy release template rule definitions between release
templates.
Release Template Rule List existing release template rules.
Create a release template rule.
Delete a release template rule.
Update a release template rule.
Role List existing roles.
Create a new role.
Update role attributes.
Delete a role.
Role Assignment List existing role assignments.
Add a role assignment.
Delete a role assignment.
User Report Definitions List existing user report definitions.
Create a new report definition.
Update a report definition.
Delete a report definition.
Assign report files to, or deassign report files from, a
report definition.s
(Sheet 5 of 6)
Supported Dimensions
Component Supported Operations
User Report Files List existing report files.
Create a new report file.
Delete a report file.
Import a file into a report file.
Export the contents of a report file.
Valid CM Relationship Type List valid change management relationships defined for
a request type.
Create a valid relationship type.
Delete a valid relationship type.
Update a valid relationship type.
Valid Sets Add a valid set object.
Delete a valid set object.
Version Branch List existing branches.
Create a new branch.
Update branch attributes.
Delete a branch.
(Sheet 6 of 6)
Syntax
The shell has the following syntax:
dmpmcli
[-user <username>
-pass <password>
-dbname <database>
-host <server>
-dsn <dsn-name>
]
[-param <parameter file>
[-file <script file> [<script arguments>]]
[-help]
[-version]
where:
Parameter Description
-user <username> Specifies a user ID that is registered on the Dimensions base
database.
-pass <password> Specifies the password for the user ID that you entered
above.
-dbname <database> Specifies the name of the base database.
-host <server> Specifies the name of the Dimensions server. The <server>
string may explicitly specify the port number of the
Dimensions listener, for example:
-host servername:5555
-dsn <dsn-name> Specifies the connection string that enables you to connect to
the database server for your Dimensions base database.
-param <parameter file> Specifies a file containing connection parameters (see the
example immediately below this table).
-file <script file> <script Specifies a file containing a script to be executed, and the
arguments>] script's (optional) arguments.
-help Displays Help for the dmpmcli syntax.
-version Displays the version of dmpmcli that you are running.
-user dmsys
-pass <password>
-dbname intermediate
-host server1
-param PC50
Executing Scripts
You can use the -file option to specify a file containing a JavaScript™ script that is to
be executed. If you do not specify a script, the interpreter enters interactive mode and
the script source is read and executed from standard input until an EOF (End of File)
character is detected (CTRL+Z on Win32 platforms and CTRL+D on UNIX platforms), or
you invoke the exit() or quit() functions.
Examples
Entering interactive mode:
Connects to the Dimensions server node dimhost and enters interactive mode. To quit
dmpmcli use the quit() or exit() functions.
Executing a script:
Connects to the Dimensions server node dimhost (assuming that the Dimensions Listener
is listening on port 5555) and executes the following script:
/home/dmsys/script/setupAttributes.js
/home/dmsys/connection.data,
/home/dmsys/script/setupAttributes.js
Predefined Properties
Scripts executing in the dmpmcli shell have access to the following pre-defined top-level
object properties:
Command Description
arguments An array containing the strings of all the arguments given at the
command line when the shell was invoked.
help() Displays usage and Help messages.
defineClass(className) Defines an extension using the Java class named with the string
argument. Uses ScriptableObject.defineClass()
Command Description
run(["foo.js", "arg0", ...]) Runs the JavaScript source file specified by the first string in the
argument, and passes the remaining arguments as that script's
arguments. The parent environment is visible but cannot be
modified.
source(["foo.js", "arg0", ...]) Runs the JavaScript source file named by the first string in the
argument, and passes the remaining arguments as that script's
arguments. The parent environment is visible and can be
modified.
system(["cmd", ...]) Runs one or several native OS commands specified by the string
argument.
loadClass(className) Loads a class named by the string argument. The class must be
a script compiled to a class file.
print([expr ...]) Evaluates and prints expressions.
quit() Quits the shell. The shell will also quit in interactive mode if you
exit() enter an EOF character at the prompt.
For an introduction to Java scripting with Rhino, refer to Rhino documentation at the
following URL:
http://www.mozilla.org/rhino/scriptjava.html
NOTE For performance reasons, running Dimensions commands from dmpmcli via
BaseDatadabase.instance.runCommand() does not refresh the object model
collections.
Interface Summary
Interface Description
AttributeBlock Represents an attribute block (a multi-value, multi-field
attribute definition).
AttributeDefinition Represents one of the following attribute definitions:
Single-value, single-field.
Single-value, multi-field.
Contains the collection of assigned object types.
Baseline Represents a baseline.
BaselineReplicationConfiguration Represents a baseline replication configuration.
BaselineTemplate Represents a baseline template and contains a
collection of assigned baseline template rules.
BaselineTemplateRule Represents a baseline template rule.
BuildArea Represents a build area.
BuildProject Represents a build project.
BuildStage Represents a build stage.
ChangeDocumentType Represents a request type, and contains the collection
of assigned browse templates.
ChangeDocumentTypeCMRules Represents a request type's change management rules.
ChdocRelationshipType Represents a request relationship type.
ChdocReplicationConfiguration Represents a request replication configuration.
DimensionsObject A marker interface representing a generic Dimensions
object.
DimensionsObjectDetails A marker interface representing generic details of a
Dimensions object.
FileFormat Represents a file format.
ItemLibrary Represents an item type's item library or the default
item library.
ItemRemoteSubordinate Represents a remote subordinate definition used by
item replication configurations.
ItemReplicationConfiguration Represents an item replication configuration.
ItemToItemRelationshipType Represents an item to item relationship type.
ItemType Represents an item type and contains the collection of
assigned file formats.
ItemTypeCMRules Represents an item type's change management rules.
ItemTypeGroup Represents an item type group.
Lifecycle Represents a lifecycle and contains collections of
lifecycle state transitions, assigned object types, and
lifecycle image revisions.
LifecycleAndTemplateAssignment Represents a lifecycle and browse template assignment
for a request type at the design part level.
(Sheet 1 of 2)
Interface Description
LifecycleImageRevision Represents a lifecycle image revision.
LifecycleTransition Represents a lifecycle state transition and contains the
collection of roles authorized to perform the transition.
LocalSubordinate Represents a local subordinate definition used by item
replication configurations.
PrimingRelationship Represents a priming relationship and associated
primed attribute mappings.
Product Represents a product and contains collections of role
assignment details, object types, baseline templates,
release templates, browse templates, request
relationship types, and valid sets.
Project Represents a Dimensions project.
ProjectStage Represents a Dimensions project stage.
RelationshipName Represents an item to item relationship name.
Release Represents a release.
ReleaseTemplate Represents a release template and contains a collection
of assigned release template rules.
ReleaseTemplateRule Represents a release template rule.
RemoteSubordinate Represents a remote subordinate definition used by
baseline replication configurations.
Replication Represents the replication administration tool.
ReplicationConfiguration Represents an abstract replication configuration.
ReplicationSubordinate Represents an abstract subordinate definition.
Report Represents a user report definition.
ReportFile Represents a report file.
Role Represents a project role.
TemplateRevision Represents an item/request type browse template
revision.
Type Represents an object type, and contains collections of
attribute blocks, attribute definitions and attribute
rules.
ValidRelationshipType Represents a valid relationship type.
ValidSet Represents a valid set.
VersionBranch Represents a version branch.
(Sheet 2 of 2)
Class Summary
Class Description
AttributeBlockDetails Represents details of an attribute block.
AttributeDataType Represents predefined attribute data types.
AttributeDetails Represents details of an attribute definition.
AttributeMappingDetails Represents an attribute mapping used in priming.
AttributeRuleDetails Represents the details of a Dimensions attribute rule.
AttributeType Represents predefined attribute types.
defaultDatabase Represents the root of the object hierarchy.
Authenticates users and contains collections of
version branches, file formats, item type groups,
lifecycles, products, relationship names, and roles.
BaselineReplicationConfigurationDetails Represents details of a baseline replication
configuration.
BaselineTemplateDetails Represents details of a baseline template.
BaselineTemplateRuleDetails Represents details of a baseline template rule.
BuildAreaDetails Represents details of a build area.
BuildProjectDetails Represents details of a build project.
ChdocRelationshipTypeDetails Represents details of a request relationship type.
ChdocReplicationConfigurationDetails Represents details of a request replication
configuration.§
ChdocSuperType Represents predefined request super types.
CMPhasePermissions Encapsulates permissions on operations that may be
applied to requests, when they are at certain
predefined lifecycle phases.
FileFormatDetails Represents details of a file format.
FileFormatType Represents predefined file format types.
ImplicitStateCode Encapsulates predefined implicit state shortcut codes
used by Dimensions baseline template rules that do
not require a normal lifecycle state to be specified.
ItemLibraryDetails Represents details of an item library.
ItemRemoteSubordinateDetails Represents details of a remote subordinate definition
used by item replication configurations.
ItemReplicationConfigurationDetails Represents details of an item replication
configuration.
ItemToItemRelationshipTypeDetails Represents details of an item to item relationship
type.
ItemTypeGroupDetails Represents details of an item type group.
LifecycleAndTemplateAssignmentDetails Represents details of a lifecycle and browse template
assignment for a request type at the design part
level.
LifecycleDetails Represents details of a lifecycle.
(Sheet 1 of 2)
Class Description
LifecycleImageRevisionDetails Represents details of a lifecycle image revision.
LifecycleTransitionDetails Represents details of a lifecycle state transition.
LocalSubordinateDetails Represents details of a local subordinate definition
used by item replication configurations.
OsType Represents predefined OS types used by user-defined
report definitions.
PrimingRelationshipDetails Represents details of a priming relationship.
ProductDetails Represents details of a product.
ProjectDetails Represents details of a Dimensions project.
ProjectStageDetails Represents the details of a Dimensions project stage.
PseudoBranches Represents predefined pseudo branches used by
Dimensions replication configurations.
RelationshipClass Encapsulates the system-defined request relationship
types Info and Dependent.
RelationshipNameDetails Represents the details of an item type relationship
name.
ReleaseTemplateDetails Represents details of a release template.
ReleaseTemplateRuleDetails Represents details of a release template rule.
RemoteSubordinateDetails Represents details of a remote subordinate definition
used by baseline replication configurations.
ReplicationConfigurationDetails Represents details of an abstract replication
configuration.
ReportDetails Represents details of a user report definition.
ReportFileDetails Represents details of a report file.
ReportScope Encapsulates predefined Dimensions report scopes.
RoleAssignmentDetails Represents details of a role assignment.
RoleCapability Represents predefined role capabilities.
RoleDetails Represents details of a role.
RuleStateSelector Encapsulates predefined baseline template rule state
selectors.
TemplateRevisionDetails Represents details of a template revision.
TransitionRoleDetails Represents details of a Dimensions role authorized to
perform a lifecycle state transition.
TypeDetails Represents details of an object type.
TypeOptions Represents predefined object type options that might
be enabled for a specific class of an object type.
TypeScope Represents predefined object type scopes.
ValidRelationshipTypeDetails Represents details of a valid relationship type.
ValidSetDetails Represents details of a valid set.
ValidSetRowDetails Represents an eight column row of a valid set.
VersionBranchDetails Represents details of a version branch.
(Sheet 2 of 2)
NOTE Both add and remove methods automatically commit changes to the
database.
In this Appendix
Use this appendix to determine what variables you can use in a template. Once you've
defined a template, you associate it with the appropriate item or request type using the
Administration Console Object Type Definitions | Templates function. You can easily edit
the template and store it back in the Dimensions CM using the export/import feature.
If you specify a filename at item creation, Dimensions CM does not insert the item header
template into the file. To apply the substitution variables, you need to manually insert
them at the desired position in the item file before creating the item.
For details of how to specify item header substitution variables, see Item Header
Substitution in the User’s Guide.
The format template contains substitution variables that are dynamically expanded when
you browse a request. Variables can represent both system-defined (Dimensions CM) and
user-defined attributes that are single or multi-valued.
You create request templates outside of Dimensions CM, usually using a standard text
editor. Though you can use the same template for multiple types, Serena recommends
that you create a template for each request type so you can manage each template
independently.
After creating a format template, you associate it to a request type. At this point, the
format template is placed under revision control by Dimensions CM and is stored in a
manner similar to items.
Rules and You can use either lower-case or upper-case text when you define variables in a
recommendations request format template.
When using RTF as a request format, any backslash (\) characters included in
attributes are removed because the backslash is treated as a qualifier in RTF.
Also, any word immediately following a backslash without a space is completely
removed.
CHANGE REQUEST
CR No:%ch_doc_id% Create Date:%create_date% Status:%current_status%
Originator:%originator% Severity:%severity% Customer Name:%customers%
Reported by:%cust_contact%
Title:%title%
Affected Product Details
Platform:%platform% Operating System:%op_sys%
Main Description:
%description%
%description_end%
Affected Item:
%affected_item%
Affected Parts:
%affected_part%
Solution Details:
%solution%
Target Release Expected effort:%exp_effort% Actual effort:%actual_effort%
Id:%target_release%
Related Requests
%related_doc%
Action History
%action_history%
CHANGE REQUEST
CR No:PAYROLL_CR_1
Originator:DMSYS
Reported by:Mike Corelli
Create Date:02-APR-2003
Severity:1_critical
Status:CLOSED
Customer Name:Acme Inc
Main Description:
Staff commented that they were unable to state if they
were ill during a holiday
Affected Item:
Affected
2 PAYROLL:SICK PAY REPORT.A-SRC;1 (Affected) DMSYS
(reports/src/rep_sick.c)
Report Sick Pay details
Response
4 PAYROLL:SICK PAY REPORT.A-SRC;2 (Response) DMSYS
(reports/src/rep_sick.c)
Report Sick Pay details
Affected Parts:
0 PAYROLL:PAYROLL.A;1 DMSYS
(PRODUCT)
Payroll Product
2 PAYROLL:REPORTS.A;1 DMSYS
(SUB-SYSTEM)
Offline statistics reports
Solution Details:
Action Message
Related Requests
Action History
1 02-APR-2003 14:15:32 DMSYS 010
DMSYS DEPT
Document created
2 02-APR-2003 14:33:37 DMSYS 010
DMSYS DEPT
Actioned document from RAISED to ANALYSED
3 02-APR-2003 14:33:41 DMSYS 010
DMSYS DEPT
Actioned document from ANALYSED to VERIFIED&CLOSED
4 02-APR-2003 14:42:59 DMSYS 010
DMSYS DEPT
Actioned document from VERIFIED&CLOSED to IMPLEMENTED
5 02-APR-2003 14:44:17 DMSYS 010
DMSYS DEPT
Actioned document from IMPLEMENTED to VERIFIED&CLOSED
6 02-APR-2003 14:47:20 DMSYS 010
DMSYS DEPT
Actioned document from VERIFIED&CLOSED to IMPLEMENTED
7 02-APR-2003 14:48:13 DMSYS 010
DMSYS DEPT
Actioned document from IMPLEMENTED to CLOSED
Dimensions CM also allows any request to be retrieved with the attribute values as they
were at any previous point that it was actioned. You can do this using the command-line
interface BC command with the /ACTION_NO option. See the Command-Line Reference
Guide for details.
Variable Description
%ch_doc_id% The request ID, which consists of the product ID, request
type, and serial number. For example: PAYROLL_CR_1
%product% The ID of the product to which the request belongs.
%base_db% The base database to which the request belongs.
%dsn% The database connection string for the Dimensions server
to which the request belongs.
Variable Description
%hostname% The name of the machine hosting the Dimensions server to
which the request belongs.
%type_head% The description of the request type.
%create_date% The date when the request was created.
%originator% The originator's full name.
%department% The originator's department.
%location% The originator's site.
%telephone_no% The originator's phone number.
%originator_id% The originator's login ID.
%group% The originator's user group.
%action_date% The date the request was last actioned.
The remaining variables change frequently during the life of the request.
Variable Description
%current_status% The current lifecycle status of the request.
%lifecycle_phase% The current phase of the request, which is determined by
the current status and any applicable rules.
%action_number% The number of the current (most recent) action.
%update_date% The date the request was last updated.
%user_name% The current user's full name.
%user_department% The current user's department.
%user_location% The current user' site.
%user_telephone_no% The current user's phone number.
%user_group% The current user's group.
%date% The current date.
%time% The current time.
Below are descriptions of the multi-valued Dimensions CM variables. For some multi-
valued variables, column variables exist that allow you to access information in a
particular column. This column information can duplicate the information provided by the
multi-valued variables, or provide additional information. Column variables also enable
you to have greater control over the formatting of each variable. See "Using Substitution
Variable Syntax" on page 316 for help with formatting.
Multi-Valued
Variable Description Column Variables
%action_history% A list of all actions performed on %ah_action_number%: The action
the request. number.
Each entry includes a short
description of the action, the %ah_date%: The action date in format
action number and date, plus the DD-MON-YYYY HH:MM:SS.
login user name, full name,
%ah_status%: The state to which this
phone number, and department
of the user performing the action. request was actioned.
%ah_user_name%: The full user name.
%ah_user_phone%: The user's phone
number.
%ah_user_dept%: The user's
department.
%ah_action_note%: The action note.
%ah_user_group%: The action history
user group.
%audit_trail_ Lists the details of the audit
failure% records for failed authentication
attempts on a request.
%audit_trail_ Lists the details of the audit
success% records for successful
authentication attempts on a
request.
Multi-Valued
Variable Description Column Variables
%affected_ A list of all baselines currently %bln_action_number%: Request action
baseline% related to the request. number when the relationship was created.
Each entry includes details about
the relationship, the current %bln_baseline_id%: The related
status of the baseline, and the baseline specification.
user who created the
%bln_baseline_type%: The type of the
relationship.
baseline.
%bln_brief_desc%: A brief description of
the baseline.
%bln_creation_method%: How the
baseline was originally created: merged,
revised, etc.
%bln_relationship%: The name of the
relationship.
%bln_status%: The current status of the
baseline.
%bln_template%: The template name
that was used to create the baseline.
%bln_user%: The OS id of the user who
created the relationship.
%bln_user_name%: The full user name
of who created the relationship.
%affected_item% A list of all item revisions %ai_action_number%: The action
currently related to the request. number.
Each entry includes the full item
specification, item library %ai_item_id%: The item's identity.
filename, the action number %ai_user_name%: The full user name.
when the relationship was
created, the type of relationship, %ai_filename%: The item's filename.
and the full name of the user who
created the relationship. %ai_brief_desc%: The item's brief
description.
%affected_part% A list of all design parts currently %ap_action_number%: The action
related to the request. number.
Each entry includes the full part
specification, the design part %ap_part_id%: The part's identity.
category, the action number %ap_user_name%: The full user name.
when the relationship was
created, and the full name of the %ap_user%: The user.
user who created the
relationship. %ap_category%: The design part
category.
%ap_brief_desc%: The part's brief
description.
Multi-Valued
Variable Description Column Variables
%parent_doc% A list of all higher-level requests %pd_relationship%: The relationship.
to which this request (child) is
currently related. %pd_doc_id%: The document's identity.
Each entry includes the higher- %pd_product%: The document's owning
level request ID, its title product.
(attribute no. 1), the action
number when the relationship %pd_status%: The status.
was created, and the full name of
the user who created the %pd_user_name%: The full user name.
relationship.
%pd_user%: The user.
%pd_brief_desc%: The brief description.
%related_doc% A list of all lower-level requests %rd_action_number%: The action
currently related to this request number.
(parent).
Each entry includes the lower- %rd_relationship%: The relationship.
level request ID, its title %rd_doc_id%: The document's identity.
(attribute no. 1), the action
number when the relationship %rd_product%: The document's owning
was created, and the full name of product.
the user who created the
relationship. %rd_status%: The document's status.
%rd_user_name%: The full user name.
%rd_user%: The user.
%rd_brief_desc%: The document's brief
description.
%update_history% A list of all modifications other %uh_action_number%: The action
than actioning to the request. number.
Each entry includes a short
description of the modification, %uh_date%: The date in format DD-
the action number and date, plus MON-YYYY HH:MM:SS.
the login user name, full name,
%uh_user_name%: The full user name.
phone, and department of the
user making the modification. %uh_user%: The user.
%uh_user_telephone_no%: The user's
telephone number.
%uh_user_dept%: The user's
department.
%uh_user_note%: The user's note.
%uh_user_group%: The update history
user group.
Multi-Valued
Variable Description Column Variables
%attribute_update A list of attribute updates made %auh_action_number%: The change
_history% to the request. document action number indicating when
Each entry includes the action the update was done.
number and date, plus the login
user name, full name, phone, and %auh_user_name%: The full user name
department of the user making of the user who did the update.
the modification, details of the
attribute and the value before %auh_date%: The date the update was
and after the change. done.
%auh_user%: The OS name of the user
who did the update.
%auh_user_telephone_no%: The
telephone number of the user who did the
update.
%auh_user_dept%: The department of
the user who did the update.
%auh_user_group%: The group of the
user who did the update.
%auh_user_note%: The user note of the
user who did the update.
%auh_attrno%: The attribute number for
which the change was made.
%auh_attr_variable%: The attribute
variable for which the change was made.
%auh_old_value%: The old attribute
value.
%auh_new_value%: The new attribute
value.
%user_roles% A list of the primary, secondary,
and leader users for every role in
the lifecycle.
%description%, The detailed description of the
%description_ request. These two substitution
end% variables must appear on
separate, successive lines in a
request template.
Multi-Valued
Variable Description Column Variables
%action%, These three variables are used %user_name%: The full name of the
%action_text%, to define a subtemplate for user entering the action description.
%action_end% action descriptions. The
%user_department%: The user's
subtemplate is part of the
department.
overall request template and
contains a list of all recorded %user_location%: The user's site.
action descriptions.
%user_telephone_no%: The user's
This subtemplate starts with the phone number.
variable %action% and ends
%date%: The date of the action
with the variable
description was entered.
%action_end%, both
appearing on separate lines. %time%: The time of the action
Between these, the variable description was entered.
%action_text% must appear
on a separate line, to define
where the text of the action
description will appear.
User-Defined Variables
User-defined variables correspond to the user-defined attributes set up for a request type.
You can define single-valued attributes as well as multi-valued attributes in list or table
form. See "Using Substitution Variable Syntax" on page 316 for information on formatting
The example below uses each type of variable. The first row uses the attributes' block
name to label the table of attributes. The second row uses the attribute prompt names to
label the column headings. The third row substitutes the actual values of the attributes.
%CUSTOMERS_BLOCKNAME%
---------------------
%CUSTOMER_PROMPT% %PHONE_PROMPT% %PRIORITY_PROMPT%
----------------- -------------- -----------------
%CUSTOMER% %PHONE% %PRIORITY%
Block attributes To define block attributes in a table, specify the block name as the table heading, as
shown in the example above (%CUSTOMERS_BLOCKNAME%). Each attribute that you
want to include in the table must have the same block name. Next, define each attribute
name and value as a column heading and column. The order of the attributes must follow
the order of the columns specified in the block attribute, from left to right. See "Using
Substitution Variable Syntax" on page 316 for information on how to format columns.
Note that if you update the block attribute name or values, you'll need to update the block
in the template.
Attribute name
--------------
Value 1
Value 2
...
Value n
Table Heading
-------------
Attr name 1 Attr name 2 Attr name 3
------------ -------------- ------------
Value 1 first value alpha
Value 2 second value beta
... ... ...
Value n nth value nu
To define the precise layout of the columns, see "Substitution Variable Syntax," below.
%<variable-name>:<c>:<w>:<s>%
where:
<c> is an integer specifying where the column starts from the left of the template, in
characters.
<w> is an integer specifying the column width in characters. Specify a positive
number to add padding to the right of the field, which ensures that if data doesn't fill
the field, the text written to the right of the field will always start at the next column
position. To eliminate padding, specify the column width as a negative number. Text
following this field will then appear in the next column following the last character of
data.
<s> is a single character (upper or lower case) that specifies the column alignment.
The available characters are:
L: Left-justified. Data will be aligned with the left-hand edge of the column. Excess
data will be truncated at the column boundary.
R: Right-justified. Data will be aligned with the right-hand edge of the column.
Excess data will be truncated at the right-hand column boundary.
C: Centered. Data will centered within the column. Excess data will be truncated at
the right-hand column boundary.
W: Wrapped. Data will be aligned with the left-hand edge of the column. Excess
data will be wrapped onto successive lines.
For example:
%CUSTOMERS_BLOCKNAME%
---------------------
%CUSTOMER_PROMPT:9:16:L% %PHONE_PROMPT:27:7:L% %PRIORITY_PROMPT:40:7:L%
------------------------ --------------------- ------------------------
%CUSTOMER:9:16:L% %PHONE:27:7:R% %PRIORITY:40:7:C%
Rules and You must either include all of the fields in the substitution variable syntax (c:w:s) or
recommendations none of them.
Generally, make the starting column equal to or greater than the previous column's
starting column value plus its width. This ensures that the columns of data are
separated by whitespace.
We do not recommend using substitution variable syntax (%<variable-
name>:<c>:<w>:<s>%) and plain substitution variables (%<variable-
name>%) on the same line. This can lead to unpredictable formatting results.
You can use a mixture of both variable types on different lines without any problem.
Substitution variable syntax is only supported for plain text substitution.
Substitution variable syntax is not supported for proportional fonts because positions
are determined by the number of characters you specify.
Do not use tab characters or insert text to the left or right of substitution variable
syntax. These actions may lead to unpredictable formatting results.
Examples
If a template is specified as:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:%token1:25:15:L% %token2:42:7:w%%token3:50:9:r%
Notice that there is a space character between the "%" characters ending "token1" and
beginning "token2", but there is no space between "token2" and "token3". This "extra"
space will be forced into the output in some circumstances illustrated below. In practice, it
may be better to include this space to make both the template and resulting output
slightly more understandable. However, it is recommended that no characters, particularly
not the "tab" character, or at most a single space character is inserted between the
substitution variable declarations within the template file (later examples will illustrate the
associated problems). If the data supplied is:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix: oneisawidestrin two three
Line prefix: four fiveisa six
Line prefix: widestr
Line prefix: ing
Line prefix: seven eight nine
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two three
Line prefix:four fiveisa six
Line prefix: widestr
Line prefix: ing
Line prefix:seven eight nine
On each row, the data within the first column has been "pushed" to the right by the fixed
text, it should start in character column 9 and be 15 characters wide therefore the last
character column in which data is displayed is 23. The first value "oneisawidestring" is
truncated at this column. The other data in the first column ("four" and "seven") has also
been "pushed" to the right by the fixed text, but because these strings are shorter than
the remaining column width they are not truncated.
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two thre
Line prefix:four fiveisawidestri six
Line prefix:seven eight nine
Remember that, with a positive column width, data within a column is padded with spaces
to occupy the full column width specified.
We know (from the previous example) that the last character column in which the first
column of data should appear is 23.
The padding characters "push" all of the second column of data to the right. The space
character in the template (between token1 and token2) appears in column 24, and so
all of the second column of data actually starts in character column 25. However,
because it was specified to start in column 22 for 18 columns, the last character
column in which the second column of data should be printed is 39.
The first character column in which the third column of data may be printed is 40,
similarly its last printing character column is 43.
Thus the strings "three" and "fiveisawidestring" are truncated to "thre" and
"fiveisawidestri" respectively. One reason why the column specifications should not
overlap is illustrated here, because the second column of data is specified as 18
characters wide and "w" (wrap). Data in this column will be wrapped at 18, 36, 54, etc.,
but the displayed column is only 15 characters wide, resulting in three characters being
truncated from each wrapped line! Do not allow the column specifications to overlap.
Consider the implications of putting a "tab" character in the template between the
"token1" and "token2" declarations (again not recommended), then the file will appear as
follows:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:%token1:9:15:L% %token2:22:18:w%%token3:35:9:r%
The "tab" has printed as blank space up to the next multiple of eight, in this case 32, and
so the string "token2" starts at character column 33. The resulting output will be:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two thre
Line prefix:four fiveisawidestri six
Line prefix:seven eight nine
which is exactly the same as with the space character, because column 24 is also a
multiple of eight. If we had put a space followed by a "tab" character in the template file,
then when printed out the template file will appear exactly the same as above, but the
printed output file would be as follows:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two thre
Line prefix:four fiveisawidestr six
Line prefix:seven eight nine
The result is very confusing because the program has put out two characters (space and
"tab") between the substitution variables "token1" and "token2", but this has resulted in
the printed columns shifting to character column 33 instead of 26. Consequently the third
column of data (three, six and nine) is also displaced by seven characters. You are
advised not to use "tab" characters in the template file.
Going back to the original template file, containing a single space between the
substitution variables "token1" and "token2", if we now change the column width
specification for "token1" from "15" to "-15" then it will not force the first column of data
to end in character column 23 (the minus sign requests no padding characters).
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two thre
Line prefix:four fiveisawidestring six
Line prefix:seven eight nine
It can be seen that the column one data finishes in character column 23, but the second
data column should start in character column 22, thus the value "two" is "pushed" to the
right, but "fiveisawidestring" and "eight" start in their correct character columns. The
space character between the "token1" and "token2" declarations in the template file has
been forced in at character column 24 before the string "two". By luck, "fiveisawidestring"
has not "pushed" the value "six" because there was space to right-justify the three
characters. However had the value "six" been "sixteen", then the result would be:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two thre
Line prefix:four fiveisawidestring sixt
Line prefix:seven eight nine
If we change the specification of "token2" width from "18" to "-18" then the result will be:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneisawides two three
Line prefix:four fiveisawidestringsixte
Line prefix:seven eight nine
There is no space separating the declarations for "token2" and "token3", so the two
strings have run together at the data column boundary, but "three" is no longer "pushed"
to the right and so this string is all displayed. If we now change the data again so that
"oneisawidestring" is shortened to "oneiswide" and "fiveisawidestring" becomes
"fiveiswide" then the result is:
....:....1....:....2....:....3....:....4....:....5....:....6
Line prefix:oneiswide two three
Line prefix:four fiveiswide sixteen
Line prefix:seven eight nine
The point to note here is that even if the columns are specified in such a way that they
overlap, the data is only "pushed" to the right by non-white-space characters in the
preceding column.
The next six examples illustrate that the user encounters while trying to create a "boxed"
table by adding characters into the template. The behavior of any character (or string of
characters) between the declaration of the substitution variables in the template file is
exactly the same as we have already seen for the space character (between "token1" and
"token2"). So if the line in the template was:
|%token1:9:-15:L%|%token2:22:-18:w%|%token3:35:9:r%|
....:....1....:....2....:....3....:....4....:....5....:....6
| oneiswide| two| three|
| four| fiveiswide| sixteen|
| seven| eight| nine|
....:....1....:....2....:....3....:....4....:....5....:....6
| oneisawidestrin|two| three|
| four| fiveisawidestring|sixt|
| seven| eight| nine|
Either of which is probably not what was intended. The situation gets even more complex
if data within the table is wrapped. The template line:
|%token1:9:-15:L%|%token2:22:-7:w%|%token3:35:-9:r%|
....:....1....:....2....:....3....:....4....:....5....:....6
| oneisawidestrin|two| three|
| four| fiveisa| sixteen|
|| widestr||
|| ing||
| seven| eight| nine|
which is clearly not what was wanted, but it does serve to illustrate what the substitution
program will do with characters in between the token declarations. In general, it is
recommended that no characters (except perhaps a single space) should be put between
the substitution variable declarations in the template file.
|%token1:9:15:L%|%token2:22:18:w%|%token3:35:9:r%|
....:....1....:....2....:....3....:....4....:....5....:....6
| oneisawidestrin|two| |thr|
| four |fiveisawidestri|six|
| seven |eight |nin|
|%token1:9:12:L%|%token2:22:7:w%|%token3:35:9:r%|
....:....1....:....2....:....3....:....4....:....5....:....6
| oneisawidest|two | three|
| four |fiveisa| sixteen|
| |widestr| |
| |ing | |
| seven |eight | nine|
|%token1:2:18:L%|%token2:22:7:w%|%token3:35:9:r%|
....:....1....:....2....:....3....:....4....:....5....:....6
|oneisawidestring | two | three|
|four | fiveisa| sixteen|
| | widestr| |
| | ing | |
| seven | eight | nine|
For completeness, the last example has the formatting data removed from the line in the
template file, but uses the same data:
Note that there are now spaces between the substitution variable declarations, resulting
in the following output text:
....:....1....:....2....:....3....:....4....:....5....:....6
oneisawidestring two three
four fiveisawidestring sixteen
seven eight nine
As expected, there is now no formatting of the data into columns. Substitutions occur one
after another across the output line, and are separated by the spaces specified between
the substitution variables in the template file.
In this Appendix
Baseline Templates
In Chapter 2, "Process Modeling Concepts", the concept of a baseline is introduced in the
topic "About Object Classes" on page 30. A Baseline Template consists of a set of rules
which are used as criteria for inclusion/exclusion of items under Serena® Dimensions®
CM control into a baseline. There are two types of baseline template. These are described
in:
"Item Baseline Templates" on page 324
"Request Baseline Templates" on page 336.
Release and Archive baselines are defined by their associated templates; whereas a
Design baseline is essentially defined by the absence of an associated template in that
the baseline will include all revisions of the items from the top level design part and its
subordinate design parts (regardless of their status). Baseline templates are unique with
respect to the base database i.e. they are not restricted to particular products. Baseline
templates are defined using the Administration Console Baseline and Release Templates
function.
There can be one rule for default item types (specified as item type *); this default rule
is applied to all relevant-items which are not covered by the other rules. The inclusion of a
default rule in a template ensures that all relevant-items receive consideration for
inclusion in a baseline.
The simplest baseline template could select the latest revision of all the items in the
current project/stream i.e. item type * and latest edit revision (*LATEST). This baseline
template allows manual selection of item revisions to be included in a baseline.
For brevity in the following pages the shortcut codes shown in the table below are used.
Rule Operation
Only one rule may be defined for each item type. The rule is used to determine, for
relevant-items of that type, what status (lifecycle state) or build stage is acceptable, or to
be preferred, for any revision to be included in a baseline. To specify the rule, any one of
the states or build stages in the normal lifecycle associated with that type may be chosen,
together with one of the rules below, which determines how that state and others in the
normal lifecycle are to be grouped and arranged in an order of preference. (A normal
lifecycle consists of a single chain of states, starting with the first state at the beginning
of the chain, and progressing upward through later states to the final state at the end
of the chain.)
Then for each relevant item which is of the type concerned within this rule, we look at
each grouping of normal lifecycle states in the order of preference indicated by the rule,
until we find the first group which is not empty, i.e. where there is at least one revision of
the relevant-item in that group. If we then find that there are two or more revisions in
that group, we always select the revision which has been created/updated most recently;
this is often, but need not necessarily be, the one with the highest entry in the revision
field. If all groups in the order of preference are empty, then that item will not be included
in any baseline specified using this template.
Note that, except when a *ALL rule is used (this is detailed later), no more than one
revision of any item is selected for inclusion in a release-baseline.
and suppose a rule is specified as STATE 2, along with the rule shown in the left-hand
column below. Then, for a relevant-item of the type concerned within this rule, the
revision which is selected for inclusion in the baseline is the most recently updated
revision chosen from those whose status is as shown in the right-hand column.
In the first and last cases the item is not included in the baseline, if no revision meets the
given requirement. In the middle three cases, we look at each "or else" in the list, only if
no revision has been found which meets the requirements up to that point; the item is not
included in the baseline, only if we reach the end of the list, still without success.
For notes and guidelines on using *BUILT and *MADE OF rules refer to this sub-topic
below.
The default rule is just a short alternative to specifying a separate rule (with the same
implicit-state in each) for every item type used by all the relevant-items, except for the
item types which have rules to themselves.
The implicit-states can, of course, be useful in other rules besides the default rule. If a
template is to select items of several different types, and for each of them to pick, say,
the latest revision at the final normal lifecycle state, it is probably more convenient (and
clearer) to choose *FINAL for the rule for each of these item types, rather than look up
and select the name of the actual final normal state in each case. (The template would
function equally effectively, specified either way.) A further advantage of implicit states
can be in defining general-purpose templates, for use by several different products. For
example, several products may have items of type XYZ, but in each product a different
lifecycle is specified for that item-type. A template consisting of the single rule: XYZ
*LATEST could be used by any of these products to create a baseline which included the
latest revision (at any normal lifecycle state) of each relevant-item of type XYZ.
a compiler build tool which produces one item of type OBJECT from one input of type
SOURCE; and
a linker build tool which produces one output item of type EXE from several inputs of
type OBJECT.
There will usually be other inputs in addition to these, but by considering this simple
example of a configuration involving just three item-types, it will become apparent how
*BUILT and *MADE OF can be used in any configuration.
Example 1
A suitable baseline template would be:
EXE *BUILT
OBJECT *BUILT
SOURCE *MADE OF
(Note that the order in which template rules are specified makes no difference to the
content of a baseline.) The effect of this template is:
first (because *BUILT processing comes at the end) to include in the baseline SOURCE
item revisions at the *FINAL (i.e. final normal) state;
then to include those OBJECT item revisions which were built (compiled) from the
SOURCE revisions already included;
finally to include any EXE item revision(s) built (linked) from some combination of
these included OBJECT revisions.
There must be a specified rule (or the default rule) to cover each stage in the build
process: if the rule for OBJECT had been omitted, then the rule for EXE could not have
included anything, because none of the build inputs for any EXE item would be present.
Example 2
Another suitable baseline template would be:
EXE *HIGHEST
OBJECT *MADE OF
SOURCE *MADE OF
(Again note that the rules could be given in any order.) This template might be used to
prepare a beta-test version of a product for release. The effect is:
first (because *MADE OF processing, like that for *BUILT, comes at the end) to include
in the baseline all the EXE items, choosing the revisions at the *HIGHEST state (i.e.
the best revision available so far for each EXE item);
then to include those revisions of OBJECT items which were used to build the revision
of each EXE item already included, unless it is found that two or more different
revisions of the same OBJECT item were used in building those EXE items (the EXE
rule would have to have included at least two different items for such a conflict to
possibly arise) – if such a conflict is found, it is flagged and reported, and no revision
of that OBJECT item is included;
then to include the SOURCE item revisions which were used to build each OBJECT
item revision already included (and therefore not flagged) – which, provided that
there is a one-to-one correspondence between SOURCE and OBJECT items, will not
result in any further conflicts being found.
Again, there must be a rule to cover each stage in the build process: if the rule for
OBJECT had been omitted, then the rule for SOURCE could not have included anything,
because the SOURCE items do not themselves belong to the made-of list of any EXE item.
(Although an EXE item is built ultimately from SOURCE items, this requires made-of lists
to be used in combination.)
Example 3
Another example of how revision conflicts could arise would be in a template consisting
of:
OBJECT *LATEST
SOURCE *MADE OF
ENV *MADE OF
(where ENV items are environment-items, some of which may be used in the build
compilations of several different OBJECT items), different revisions of one ENV item might
have been used in the compilations which produced the OBJECT items already included.
Example 4
It is valid to have a template with both *BUILT and *MADE OF rules, such as:
EXE *BUILT
OBJECT *LATEST
SOURCE *Revision that makes selected outputs
It is necessary that the other rule(s) in such a template include items which are in
between in the build process. This means that the rules for *BUILT inclusion and those for
*MADE OF inclusion will never conflict with each other. In this example OBJECT items
have been included first, followed by both the EXE revisions built from them and the
SOURCE revisions used to build them.
Example 5
It is not valid to have a template consisting solely of *BUILT and/or *MADE OF rules. For
example a template of simply:
OBJECT *BUILT
SOURCE *MADE OF
would include nothing, because there is nothing selected to start off with, and so neither
the *BUILT nor the *MADE OF processing could possibly find anything to qualify for
inclusion.
Note 1: *MADE OF rules do not guarantee that the baseline will include the entire contents of
any made-of list. If a complete made-of list is to be assured of being included, then:
either the template should be designed to use *BUILT; or else the *MADE OF rules
must be sufficiently all-embracing to cover the made-of list. For example:
EXE *HIGHEST
* *MADE OF
could be used to include all the made-of lists for the included EXE items; but only
provided that the scope of the baseline is large enough to include every configuration
part which was specified or implied in each of the build processes used.
Note 2: *BUILT and *MADE OF rules are incompatible with *ALL rules: neither *BUILT nor
*MADE OF may be used in any template which contains one or more *ALL rules.
Cross-Product Baselines
A cross-product baseline is one which includes design parts and/or items which belong to
two or more products, because within the baselined design-structure USAGE relationships
have been created (using the Dimensions functions Relate Design Part Usage and/or using
Relate Item to Part) and these have specified design parts and/or items in other
product(s).
The product whose design-structure (or a sub-tree of it) is being baselined, is referred to
here as the baselining product, and all relevant-items which do not belong to this
product, are called foreign-items belonging to foreign products.
The remaining requirements and limitations concern the lifecycles associated with these
item types, in the various process models for all the products represented in the baseline.
Obviously, the most straightforward case is where, for each item type concerned, taken in
turn, that item type uses the same lifecycle in every process model. If this is indeed the
case, then there are no further complications, and revisions of all relevant-items,
including foreign-items, can be selected using the procedures already described.
However, it may be impracticable for different products to share identical lifecycles for the
same item type. Therefore when the lifecycle used for an item type in a foreign product
differs from that used for the same item type in the baselining product, the extent to
which these two lifecycles need to be similar to each other needs to be examined in some
detail.
First, suppose the normal lifecycles in the two lifecycles are identical: the same state
names appear in the same order; and the lifecycles differ only in the number and/or
arrangement of the lifecycle transitions which do not lie on the normal path. Then there is
no further problem for relevant-items of that type in either product: as far as a
baseline-template is concerned, the two lifecycles function in an identical manner,
because their normal lifecycles are equivalent.
We now look at the cases where the normal lifecycles for an item type differ in some
respect between the baselining product and a foreign product. We need to consider
individually the different alternatives for the template rule for that item type, starting with
the simplest.
*ALL rule
This rule raises no problems, as it selects all revisions of a relevant-item, regardless
of their lifecycle states. This applies equally to foreign-items.
*BUILT and *MADE OF rules
These rules also raise no particular problems, as they are processed in an entirely
different way, and are not directly concerned with normal lifecycles. The *BUILT and
*MADE OF procedures are applied equally to relevant-items of both the baselining and
foreign products.
*LATEST rule
This rule is handled in a special way, the effect of which is that the normal lifecycles
for the baselining and foreign products do not need to correspond with each other at
all. For a relevant-item of the baselining product, the latest revision is selected from
all at any of the states in the baselining product's normal lifecycle; and for a
foreign-item, the latest revision is selected from all at any of the states in that foreign
product's own normal lifecycle.
LFS rule with a specific state
This is a more general version of *LATEST and is handled as follows. The specific state
given is looked up in the normal lifecycle for the baselining product. Let us suppose
the normal lifecycle has six states and that the specified state is number 3 (the first
state is number 1, and the final normal state, in this case, number 6). For a
relevant-item of the baselining product, the latest revision would be selected from all
those at any of the states whose numbers are 3, 4, 5 and 6. For a foreign-item, we
look up the foreign product's normal lifecycle for the names of the states which are
number 3 (the same number as that of the specified state) or greater, and select the
latest revision from those at any of these states.
This would mean, if this normal lifecycle had nine states instead of six, that there
would be seven states from which a selection could be made (numbers 3 to 9
inclusive) instead of four in the baselining product. In an extreme case, if the normal
lifecycle for a foreign product had only two states (unlikely, but possible), then there
would be no states from which to select, and so no revision could be selected for a
foreign-item of this item type in that product.
One example of this rule, which could be very useful, is to specify LFS along with the
state which is number 2 in the baselining product's normal lifecycle. The effect of this
rule would be that, for every relevant-item of that item type in any product, the
revision selected would be the latest at any normal state, excluding those which had
initial status; i.e. it would guarantee that the selected revision had been actioned at
least once after modification.
All other codes and implicit states *FINAL and *HIGHEST
A rule of this kind requires a significant degree of consistency between the normal
lifecycles in the baselining product and a foreign product, in order to satisfactorily
select a revision of a foreign-item. What happens is that only the baselining product's
normal lifecycle is consulted, and the search (in the appropriate order of preference)
is performed on all relevant-items of that type (i.e. associated with that normal
lifecycle), including foreign-items, using the state names in the baselining product's
normal lifecycle.
So, to take one of the simpler cases, if the rule specified *FINAL, and the final normal
state in the baselining product's lifecycle was DONE, then DONE would at least have
to appear somewhere in the corresponding lifecycle for the foreign product, and the
foreign-item's revision selected would be the latest (if any) which had DONE status,
regardless of what DONE actually meant in the foreign product's lifecycle.
It is therefore necessary, if any of these codes are going to be used, to have sufficient
agreement among the normal lifecycles for all the products concerned, as to the
meaning of most, if not all, of the state names used, in order to ensure that the
selected revision of a foreign-item is the one actually desired.
Apart from *ALL, a suspended revision; is never selected for inclusion in a new
release-baseline, created using a baseline-template. The selection processes already
detailed (apart from those for *ALL) are applied exactly as if the suspended revisions did
not exist.
If the selection is by a *ALL rule, and a checked out revision would have been among
those selected (if it had not been checked out), then this is flagged, and the requested
baseline is not created.
Apart from *ALL rules, the selection processes already detailed are applied exactly as if
the checked out revisions did not exist.
and suppose an item of type XYZ (OWNED by an included, non-suspended design part)
exists in five revisions (none of which is currently checked out or suspended) as follows,
each most recently updated on the date shown, and then actioned to the lifecycle state
shown:
Last
Revision Updated Current State
1 1/1/2003 TESTED
2 1/2/2003 TESTED
3 1/4/2003 COMPLETED
4 1/3/2003 COMPLETED
5 1/5/2003 PRELIMINARY
Then consider in turn each of the following alternative choices of template rule for item
type XYZ. If the template rule were as shown, then for the above item, the revision which
would be selected, together with the reason for this selection, is as shown alongside.
Revision
Lifecycle State Code Selected Reason
DESIGNED Latest from state (LFS) 3 1, 2, 3 & 4 qualify; 3 is
latest
DESIGNED Most progressed state 2 Latest at nearest-to-final
above specified state or state
specified state (MPS)
DESIGNED Specified state or most 2 Latest at nearest-to-final
progressed state (SMP) state
DESIGNED Specified state or next 3 Latest at next state up
existing state upward
(SUP)
DESIGNED Specified state only None None at DESIGNED state
(EQS)
PRELIMINARY Most progressed state 2 Nearest-to-final state
above specified state or preferred
specified state (MPS)
PRELIMINARY Specified state or most 5 Specified state preferred
progressed state (SMP)
*All revisions 1,2,3,4 Includes everything
(*ALL) &5
*Latest edit 5 Latest of all at normal
revision states
(*LATEST)
*Latest edit None None at final state
revision at final
state in lifecycle
(*FINAL)
Revision
Lifecycle State Code Selected Reason
*Latest edited 2 Work back from final
revision at the state; take latest at 1st
most progressed state found
state
(*HIGHEST)
*Revision built ? Cannot say; see following
from selected notes
inputs (*BUILT)
*Revision that ? Cannot say; see following
makes selected notes
outputs (*MADE
OF)
Notes 1 "None" means that, if this were the template rule, then this item would not appear in
the baseline.
2 The revision (if any) which would be selected by *BUILT cannot be determined from
the information given. This is because if this is a built item, the revision selected
would depend on the corresponding revision(s) of the input item(s) used to build it,
and those revisions would be selected by template rules for other item-types.
3 The revision (if any) which would be selected by *MADE OF cannot be determined
from the information given. This is because if this is an item selected because it is in a
made-of list of some built item, the revision selected would depend on which revision
of the built item was included, and that revision would be selected by a template rule
for some other item-type.
4 Revisions 1 or 4 could not be selected by any rule (except *ALL, and possibly *BUILT
or *MADE OF, because in each case another revision, more recently updated, exists at
the same lifecycle state.
A request baseline template consists only of request template rules – it will not allow the
addition of rules using item types. Conversely, an item baseline template does not allow
the addition of request baseline template rules.
The template rules will be processed in exactly the same way they are for item templates,
that is, requests will be selected based on the type, status, and the baseline status code
that was specified. For example, if a template had a rule that said that:
all requests of type PR,
at status ACCEPTED,
with the baseline status code EQS
were to be considered, then all the requests of type PR, at the status ACCEPTED only,
would be used for inclusion into the baseline.
Once this list of requests has been determined, then only those items that are related to
those requests with either an In Response To or, optionally, an Info relationship will be
included into the baseline. However, because the baseline that is being created is a
release baseline, only one revision of each item will be included in the baseline (not all
revisions, as would be the case for a design baseline). This means, that even though the
requests being selected may contain multiple revisions of the same item, the final
baseline will only contain one revision of all these possible items.
To ensure that only one revision of an item is included in the final baseline in
circumstances where multiple item revisions are related to requests, only the latest item
revision will be selected using that item's pedigree. If item revisions are in conflict, that is,
no common successor to these items are found, then the creation of the baseline will fail
with an appropriate error message.
When the baseline has been created, the requests that were used to create it will be
related as In Response To that new baseline.
Constraints
To enforce a consistent model with its behavior with respect to items only, the following
additional constraints apply to creating a baseline with respect to cited requests:
1 Requests that are either at a closed or off-norm lifecycle state will not be processed
by the SUP baseline code.
3 Only requests related through a dependency relationship, that is, DEPEND, will be
included in traversal scans.
4 If a request related through a dependency relationship does not fulfill the criteria
specified in the request template rules, then that request will be ignored—as will
every other request that is a child of that request. This means, that for a situation
where N levels of requests are related together in a chain through dependent
relationships, for example, CR_1 → CR_5 → CR_7 → CR_9 → CR_12, if CR_7 fails to
match a template rule, then it, and CR_9 and CR_12 will be ignored from any further
processing.
5 Only requests that are owned by the product on which the baseline is being created
will be processed. Any requests owned by other products will be ignored—this
includes children that such requests might have.
6 Only parts or items that are owned, or have usage relationships to the parent part
specified when the baseline is created will be included in the final baseline. This
means, that if a request refers to affected parts and/or items that may be out of
scope – that is, not owned by or related to the parent part or any of its children – then
these parts and items will be ignored.
Release Templates
In Chapter 2, "Process Modeling Concepts", the concept of a release is introduced in the
topic "About Object Classes" on page 30. A Release Template:
Defines a set of user-defined rules or criteria by which baselined design parts are
selected for inclusion in a release. This rule is then applied to that design part and
also to any subordinate to it in the design-structure tree, unless and until another rule
specifies any such subordinate design part, in which case that other rule overrides for
that sub-tree, and so on. Alternatively, a rule may be applied to ALL design parts of
the product.
If asterisk (*) is specified as the design part, then the rule will be applied to all design
parts for which no specific item type rule exists i.e. "select all". The definition of a
default rule in a template ensures that all design parts within a baselined structure
are considered for inclusion in the release.
Defines a set of user-defined rules or criteria by which baselined items are selected
for inclusion in a release.
If asterisk (*) is specified as the item type, then the rule will be applied to all items for
which no specific item type rule exists i.e. "select all". The definition of a default rule
in a template ensures that all items within a baselined structure are considered for
inclusion in the release.
If hyphen (-) is specified as the item type, then the rule will be applied to no items
(this is used to inhibit the selection of items for some sub-tree of the design part
structure).
Optionally specifies operating system subdirectories to be added to the release
pathname specified by users (directory into which the above are to be copied). The
subdirectory must be a relative format (such as xxx/yyy UNIX or xxx\yyy
Windows). If a subdirectory is specified, the items of all types specified by the rule,
for all design parts selected by the rule, are placed in the subdirectory with the leaf
node portion of their project filename. On the other hand, if a subdirectory is not
specified, the items' project filenames will be used, relative to the operating system
release directory the user requests for the release.
Any operating system directories or subdirectories which do not exist, Dimensions CM
creates as and when they are needed (subject to the user having the necessary
operating system file access rights for such directory creation).
Release templates are defined using the Administration Console Baseline and Release
Templates function.
NOTE All release-template rules apply only to the items selected by the baseline
specified for a release. If a release-template is not used, then all the items in the baseline
are placed in a single release directory, their project filenames being used relative to the
operating system release directory the user requests for the release.
Different release-templates may be used with the same baseline to create a number of
different release-configurations (e.g. test configurations of subsystems) or to make
available different groups of items (e.g. user documentation).
In this Appendix
Overview
The e-mail notification system in Dimensions CM is designed to provide more control over
e-mail notification and content, and also to provide a mechanism to allow administrators
to configure which particular users/groups receive e-mail notifications. This new
notification system is designed to work in tandem with the existing e-mail notification
mechanism and if switched on via subscriptions, will replace the standard default
Dimensions CM e-mail notifications.
There are a number of standard ("system") notifications defined to which a user or group
can be subscribed. (See "Notification Types" on page 343.) This subscription process is
performed by an administrator with the appropriate privilege (as described in "How Do
You Use the E-mail Notification System?" on page 342). Once one or more users have
been subscribed to a particular notification then the default e-mails, which are usually
sent to everyone with the appropriate role, will be "switched off" in favor of the new
subscriptions. In this way, an administrator can configure users to only receive those
notifications that are relevant to them and disable all other "spam" e-mail.
When using the default e-mail notification system, e-mail messages are sent immediately
whenever a command is run. This can mean that systems with a slow connection to the e-
mail server can suffer from an unnecessary time lag before the command completes. The
new e-mail subscription system however, writes every e-mail event to the database to
allow it to be processed "on-batch" via a new utility called dmemail at a later time. This
means that commands are no longer tied to the response time of the e-mail server, and
also allows a system administrator much more flexibility as to scheduling when e-mails
are processed.
The dmemail utility is a new application which allows much more fine-grained control over
the processing of e-mail than is provided by the default mail system, and can be
configured to run either as a scheduled task or "on demand" as desired by an
administrator. This utility will go through all the e-mail events that are pending to be sent,
apply all the various e-mail templates, and then send the resulting e-mail to the
subscribed users. For more information on the dmemail utility see "Using the dmemail
Utility" on page 346.
As mentioned above, this new e-mail subscription model supports the use of e-mail
templates to allow the administrator to customize the e-mail content which is sent to the
end user. The templating syntax, which is used within the template files, is the same as
that used for writing remote jobs and build templates, which means it can support
complex IF/ELSE constructs and other control conditions For more information on this
syntax, please refer to the Dimensions Build User's Guide. The location of the templates is
controlled by the variable DM_EMAIL_TEMPLATE_DIR in the Dimensions CM file dm.cfg,
but by default, is under the $<DM_ROOT> directory in a subdirectory called
email_templates. One template file exists for each subscribable notification, and can be
found using the Administration Console. By default, these templates are written to
support HTML syntax.
The process of subscribing users to e-mail notifications using the Administration Console
is described in "About Mail Notifications" on page 106, or you can use the following
commands below. These are more fully described in the Command-Line Reference Guide.
SUB: Subscribe user/group to notification.
USUB: Unsubscribe user/group to notification.
LMNR: List mail notification rules.
The templates supplied, and the variables available, are described in "Notification
Templates" on page 352. For more details on the email templating language, see Scripts
and Templates in the Developer's Reference.
The dmemail command-line utility is described in this Appendix in "Using the dmemail
Utility" on page 346. The options for the configuration file are described in "The
Configuration Parameters" on page 348.
Notification Types
The predefined notification types to which users and groups can be subscribed are listed
below.
Object
Notification Name Type Class Description
DEMOTE_BASELINE_NOTIFICATION Demote Baseline A baseline has been demoted.
DEPLOY_BASELINE_NOTIFICATION Deploy Baseline A baseline has been deployed.
PENDING_BASELINE_NOTIFICATION Action Baseline A Dimensions baseline has come into your
inbox. This is a mail notification that will be
triggered when a baseline comes into
someone's inbox. This can be as a result of a
creation or an action.
PROMOTE_BASELINE_NOTIFICATION Promote Baseline A baseline has been promoted.
ROLLBACK_BASELINE_NOTIFICATION Baseline This event does not have any effect, and will
be removed in a future release.
UPDATED_BASELINE_ATTRIBUTE_NOTIFI Update Baseline This is a mail notification that will be
CATION triggered when someone updates an
attribute of a baseline in your inbox.
ADD_ITEM_PROJ_NOTIFICATION Add Item An item has been added to a project. This is
a mail notification that will be triggered when
someone adds an item that is in your inbox
to a project.
DELEGATED_ITEM_NOTIFICATION Delegate Item A Dimensions item has been delegated to
you. This is a mail notification that will be
triggered when an item comes into
someone's inbox as a result of a delegation.
DEMOTE_ITEM_NOTIFICATION Demote Item An itemhas been demoted.
Object
Notification Name Type Class Description
DEPLOY_ITEM_NOTIFICATION Deploy Item An itemhas been deployed.
ITEM_LOCK_NOTIFICATION Lock Item An itemhas been locked in a stream.
ITEM_UNLOCK_NOTIFICATION Unlock Item An item deployment has been unlocked in a
stream.
MERGE_ITEM_CONFLICT_NOTIFICATION Merge Item An item needs to be merged. This is a mail
notification that will be triggered when
someone needs to merge an item conflict.
PENDING_ITEM_NOTIFICATION Action Item A Dimensions item has come into your inbox.
This is a mail notification that will be
triggered when an item comes into
someone's inbox. This can be as a result of a
creation or an action.
PROMOTE_ITEM_NOTIFICATION Promote Item An itemhas been promoted.
REMOVE_ITEM_PROJ_NOTIFICATION Remove Item An item has been removed from a project.
This is a mail notification that will be
triggered when someone removes an item
that is in your inbox from a project.
ROLLBACK_ITEM_NOTIFICATION Rollback Item An item deployment has been rolled back
from an area.
UPDATED_FILENAME_NOTIFICATION Update Item A project filename has been updated. This is
a mail notification that will be triggered when
someone changes the project filename of an
item in your inbox.
UPDATED_ITEM_ATTRIBUTE Update Item This is a mail notification that will be
_NOTIFICATION triggered when someone updates an
attribute of an item in your inbox.
DELIVERY_NOTIFICATION Deliver Project A deliver has been made to a stream.
PENDING_PROJECT_NOTIFICATION Action Project A Dimensions project has come into your
inbox. This is a mail notification that will be
triggered when a project comes into
someone's inbox. This can be as a result of a
creation or an action.
PROJECT_LOCK_NOTIFICATION Lock Project A project or stream has been locked.
PROJECT_UNLOCK_NOTIFICATION Unlock Project A project or stream has been unlocked.
UPDATED_PROJECT_ATTRIBUTE Update Project This is a mail notification that will be
_NOTIFICATION triggered when someone updates an
attribute of a project/stream in your inbox.
UPLOAD_NOTIFICATION Upload Project An upload has been made to a project.
DELEGATED_REQUEST_NOTIFICATION Delegate Request A Dimensions request has been delegated to
you. This is a mail notification that will be
triggered when a request comes into
someone's inbox as a result of a delegation.
DEMOTE_REQUEST_NOTIFICATION Demote Request A requesthas been demoted.
DEPLOY_REQUEST_NOTIFICATION Deploy Request A requesthas been deployed.
Object
Notification Name Type Class Description
PENDING_REQUEST_NOTIFICATION Action Request A Dimensions request has come into your
inbox. This is a mail notification that will be
triggered when a request comes into
someone's inbox. This can be as a result of a
creation or an action.
PROMOTE_REQUEST_NOTIFICATION Promote Request A request has been promoted.
REQUEST_CLOSURE_NOTIFICATION Update Request This is a mail notification that will be
triggered when a request has reached its end
of lifecycle state.
ROLLBACK_REQUEST_NOTIFICATION Request This event does not have any effect, and will
be removed in a future release.
UPDATED_ACTION_DESCRIPTION Update Request The action description of a request in your
_NOTIFICATION inbox has been updated. This is a mail
notification that will be triggered when
someone adds or updates an action
description of a request in your inbox.
UPDATED_DETAILED_DESCRIPTION Update Request The detailed description of a request in your
_NOTIFICATION inbox has been updated. This is a mail
notification that will be triggered when
someone updates the detailed description of
a request in your inbox.
UPDATED_REQUEST_ATTRIBUTE Update Request This is a mail notification that will be
_NOTIFICATION triggered when someone updates an
attribute of a request in your inbox.
UPDATED_REQUEST_RELATIONSHIPS Update Request This is a mail notification that will be
_NOTIFICATION triggered when someone relates or unrelates
an object to a request in your inbox.
UPDATED_REQUIREMENT_NOTIFICATION Update Require A requirement has been updated. This is a
ment mail notification that will be triggered when
someone has made a change to a
requirement that is related to a request in
your inbox.
CREATE_USER_NOTIFICATION Create User A new Dimensions user has been created.
This is a mail notification that will be
triggered when a new user has been created
in the base database. This is an
administration mail notification.
DELETE_USER_NOTIFICATION Delete User A Dimensions user has been deleted. This is
a mail notification that will be triggered when
an existing user has been deleted from the
base database. This is an administration mail
notification.
E-mail Digesting
When a user or a group is subscribed to a notification, there is the option to make the
subscription a digest type, which means that all e-mails for that user, or group of users,
will be "batched up" and sent as a single digest e-mail. This will allow users or groups to
receive a summary of all the activity that has been undertaken which matches their
subscriptions.
What is dmemail?
The dmemail utility is a command that processes queued notification events held in the
Dimensions CM database and turns them into actual e-mails. It is responsible for
expanding the e-mail templates with the mail content and sends the resulting e-mail to
end users.
Modes of Operation
dmemail is a command-line utility that can be run in three ways:
Direct from a command prompt.
Automated via an existing customer scheduling system, such as cron.
Automated via the Dimensions listener itself.
Security
dmemail needs to run from a user account that is part of the Dimensions "ADMIN" group.
When dmemail is scheduled using the Dimensions listener, then it will run as the same
user as the dmpool process, which is specified in the file %DM_ROOT%\dfs\listener.dat
(Windows) or $DM_ROOT/dfs/listener.dat (UNIX).
Command-Line Syntax
The command-line syntax for this utility is:
dmemail [config-file]
%DM_ROOT%\dfs\email_config.dat (Windows)
or
$DM_ROOT/dfs/email_config.dat (UNIX)
Other parameters can either be specified as part of the command line or entered in the
configuration file. See "The Configuration Parameters" on page 348 for details of the
parameters.
Subsequent parameters when entered on the command line are used as key-value pairs.
If you want to use the default configuration filename and have parameters, use "-" as
parameter 1.
Parameters entered on the command line take precedence over those options specified in
the configuration file.
If you need spaces in the parameters, use double quotes. The parameter names are not
case sensitive, and values of Y/y and N/n are equivalent.
Examples:
dmemail
dmemail -?
dm.cfg parameters
The following entries are required in the dm.cfg file. For details of editing this file see the
General Administration section of the Administrator's Guide:
DM_TMP
Dimensions temporary file folder. This is used as default for working files, if other
(e-mail specific) options are not specified.
DM_MAILS
Symbol used by existing Dimensions e-mail system to interface with an Operating
System mail command. This is documented in the General Administration section
of the Administrator's Guide.
DM_MAILS_HTTP
Custom version of the above symbol for use with HTML e-mail. Some mail
commands have special options to enable HTML mail. For example, the Dimensions
supplied program "pcmsmail" needs to be given the "-i" option. This would be
specified in this variable.
Here is an example of the last two symbols:
DM_EMAIL_AUTOSTART_TIMES
This variable is used to control the automatic startup and running of the dmemail
application. It specifies the scheduled times that dmemail is required to start
processing content.
DM_EMAIL_AUTOSTART_DIR
Working files and a log of activity is recorded in this directory when dmpool is
managing the dmemail process. The default is DM_TMP.
DM_EMAIL_MSG_LEVEL
A severity level indicating the level of event that will generate a record in the log. 0
generates the most information. Higher values restrict the messages to more
severe events. To only see information about serious errors, set this to 4.
DM_EMAIL_TEMPLATE_DIR
This overrides the default location of the e-mail templates, if required. If not
specified, the default is %DM_ROOT%\email_templates (Windows) or $DM_ROOT/
email_templates (UNIX).
These keywords and their parameters are described in the sections that follow, grouped
under functional headings.
Database processing
DATABASE
Multiple databases can be processed in sequence, by specifying a keyword
"DATABASE_i" where i is an integer (such as 1,2 3) for each subsequent database to
be processed. In each case, the DATABASE key specifies the usual Dimensions CM
"connection string" for a database, i.e. as you would for DMDB. If the database
requires a password to allow the user id to connect, then this can be set using the
dmpasswd utility documented in the Command-Line Reference Guide.
Example:
DATABASE_1 =intermediate@dim10
DATABASE_2=intermediate@dim10-test
DATABASE_3=db2user/db2passwd:intermediate@dim10-db2-test
HOST
DMUSER
HOST_<i>
DMUSER_<i>
These operate similarly to DATABASE_<i> in the case where multiple databases are to
be processed.
Processing Options
PROCESS_FILES
Y or N
Indicates if dmemail should process the stored "e-mail files" and physically "post"
them to the e-mail system. Setting this to N is very useful in testing to avoid a flood
of unwanted e-mails.
Temporary files are created, used, and then deleted for each email. During a long run
of dmemail, only a handlful of temporary files should exist.
Debugging options
These options should only be changed if requested by Serena Support personnel.
These debug options are probably best specified in the command line. if you have set
debug=y, then the options in effect are printed in the log.
PROCESS_ROWS
Y or N
Indicates if dmemail should generate new "e-mail files" on disk from the event record
rows in the database. Setting this to N means that new events are not processed,
which is helpful if you are working on fixing a problem with existing e-mails.
DELETE_ROWS
Y or N
Indicates if dmemail should delete rows from the database once they have been dealt
with. This is essential in a live operation, or the same e-mail will be regenerated
repeatedly. However, in testing it may be useful to keep the data for a second test.
DELETE_FILES
Y or N
Indicates if dmemail should delete the physical "e-mail files" after posting them. This
is essential in a live operation, or the same e-mail will be generated repeatedly.
However, in testing it may be useful to avoid deleting the body files, so you can
inspect them for testing purposes
LOGGING
Y or N
LOG_FILE
<filename>
DEBUG
Y or N
Add very detailed information to output, including the "symbol table" contents. The
symbol table dump will contain details of all symbols available for expansion in the
template.
i is a small number starting at 0, and is used to specify a list of locations where e-mail
templates can be found. The reason for allowing a list of locations is so that custom
versions of supplied templates can be stored in a local directory that is searched
ahead of the system directory.
LOCALE_MAP_<i>
LOCALE_DIR_<i>
Where i is a small number, starting at zero. For each value of i, these two symbols
specify a mapping from a "locale name" to a directory name.
The locale name is a string defining the preferred "language" for a particular e-mail
recipient. The resulting directory name is then added to the front of the search list
defined above. This allows certain e-mail templates to be redesigned in a language-
sensitive way, while at the same time allowing the default templates to be used if no
such customizing has been provided.
example:
TPL_SEARCH_0=c:\custom\email_templates
TPL_SEARCH_1=c:\Serena\Dimensions\12.1\email_templates
LOCAL_MAP_0 =GERMAN
LOCAL_DIR_0 =c:\custom\email_templates\german
In this example, a template will be searched for in the following places:
default:c:\custom\email_templates
c:\Serena\Dimensions\12.1\email_templates
German:c:\custom\email_templates\german
c:\custom\email_templates
c:\Serena\Dimensions\12.1\email_templates
Miscellaneous options
MAX_EMAIL_LIST_SIZE
Integer
E-mails are sent using a shell command line, which may have a limited length. If this
(MAX_EMAIL_LIST_SIZE ) is set to a fairly low value (in characters), then when large
distributions are generated, they will be split into multiple e-mails, each with a
smaller list of recipients.
DEFAULT_SUBJECT
Specifies a default subject line that will be used if the template being processed does
not specify one. Most templates will set the subject line, as this allows variables (such
as item names) to be show in the subject itself.
DEFAULT_SUBJECT_MULTIPLE
When multiple e-mails are merged together in a digest structure, this variable
specifies what the default subject will be.
MULTIPLE_TEMPLATE
This names a special template that is a "container" that holds the individual pieces of
a merged (digest) e-mail. It can be customized to achieve certain formatting effects.
ENVELOPE
This names a special template which is used like an envelope, wrapping up the e-mail
body just prior to posting. The supplied example, "html-envelope-outer.tplt" adds the
necessary HTML syntax to the top and bottom of the e-mail, to make a valid HTML
message. It could be customized to add customer-specific branding to all
Dimensions CM e-mails.
EMAIL_SLEEP
In some configurations, SMTP servers cannot respond quickly enough to a large
number of e-mails, such as may be generated by dmemail. This could, for example,
be the result of an anti-spam policy implemented by the SMTP server. This parameter
specifies a value in seconds which is used as a delay between sending messages. By
default, this figure is set to 30. If you do not have any such spam policy in place, then
it is highly recommended that you lower this to a figure of 1 or 2.
EMAIL_DIRECTORY
E-mails are first created as files, in this directory. If this is not specified, the default at
DM_TMP will be sent.
DIGEST
This controls the way emails are digested.
0 - No digesting for super-fast processing of an email backlog. This directly sends
each row.
1 - (default) The current behavior based on digest flag against user subscription
2 - Forced mode - all messages will be digested, to produce only one email per user
no matter what. This could be used to ease the burden on the mail server in a backlog
situation.
DIGEST_THRESHOLD
This sets the limit for the number of messages to be digested.
Numeric value, default 10000.
If the number of rows to be processed is larger than this, then dmemail refuses to
work unless DIGEST=0 is in effect. This limit can be overridden when large runs are
required.
FILTER_SQL
This specifies a "sql where clause component" that will be used to select rows from
the MAILS2PROCESS table. An administrator can use this to great effect to test out
situations on a live system without sending thousands of mails.
Here are some examples:
dmemail - "filter_sql=obj_uid=12345"
dmemail - "filter_sql=create_date between xxxx and yyyyy"
dmemail - "filter_sql=rel_class = 7"
The full SQL generated is shown in the log when debug=y.
PURGE_ROWS
Y/N
If Y, then rows that are ignored by the filter used above, are purged from the table. If
the FILTER_SQL specified a condition that requested only recent rows, then this would
delete all the older rows.
This works by inverting the condition specified with FILTER_SQL
NO_STOPFILE
Y/N
Specifying this in the config file will allow the command line program to use
scheduling mode, just as if it had been started from the Dimensions pool process. The
syntax is:
dmemail -dmpool
For this to work, the dm.cfg variables that control scheduling need to be setup.
ALLOW_MISSING_SYMBOLS
If this is set to Y, then the email template will expand, even if some variables are not
defined. This is very useful for processing a batch of emails which have a known minor
problem (such as a missing description). In place of the symbol, text will be
generated as in the following example:
Template before expansion:
Request: %DMTEST.
Email after expansion:
Request: [symbol DMTEST is not defined]
Notification Templates
The default e-mail templates can be found in the directory: <DM_ROOT>/
email_templates/
The table below is a list of the template names used for each of the default notifications.
For each of the following notification templates, the following variables are valid.
NOTE System-defined and user-defined attributes are associated with a particular object
type. You can only use attributes in a notification template that belong to the object type
for which that notification is generated.
Please note, not all of the variables specified above will be populated under all
circumstances. Trying to use variables that are not populated under all circumstances will
result in either the variable being given a blank value, or a template error when trying to
process that template. Please see below for more details on how to resolve such issues.
Multi-Value Attributes
The following variables can be used for multi-value attributes:
ATTR_<name>_VALS for user-defined attribute values
ATTRS_<name>_VALS for system defined attribute values
where <name> is the attribute name.
For example:
)IFDEF ATTR_<name>
<P>List of ~(ATTR_<name>(0)). values:<BR>
<UL>
)REP ATTR_<name>_VALS
<LI>~ATTR_<name>_VALS.</LI>
)ENDR
</UL></P>
)ENDIF
If you wish to display a multi-field multi-valued attribute, you would need to display the
grouped multi-value attributes that it consists of.
expect, then you might have introduced errors into the templates that need to be
corrected as described above.
NOTE Please be aware that some mail servers implement anti-spam policies by filtering
out invalid e-mail addresses. When using mail notifications, please ensure that all the e-
mail addresses specified for your users are correct (see User Registration in the
Administration Console). Failure to do so may result in e-mail notifications being blocked
by the mail server.
In this Appendix
Privilege Overview
In Serena® Dimensions® CM 12.2.1, all implicit privilege definitions that used to be
encapsulated in role definitions and inboxes have now been made explicit and grantable
to users, roles, or groups based on certain rules. This is to allow the maximum level of
flexibility when allowing certain users to do things. This appendix lists what those
privileges are and what rules can be used to say when those privileges apply. It is
important to note that certain system roles like PRODUCT-MANAGER, CHANGE-MANAGER,
PARTS-CONTROLLER, and WORKSET-MANAGER amongst others, still retain their implicit
abilities, although in some circumstances these abilities can be changed by altering the
default privilege set up.
Privilege Rules
This appendix lists all the privileges that are available in Dimensions CM together with the
available rules for each privilege. Each rule specifies the circumstances under which a
privilege is to be activated for a user. Not all of the rules are available for all of the
privileges.
The procedure for assigning privilege rules in the Administration Console is described in
"Managing Privileges" on page 102.
The complete set of privilege rules is listed below together with their descriptions.
When you create a new base database or upgrade an existing Dimensions 9 installation,
the default grant rules for the Update Files from Project/Stream and Deliver Files
into Project/Stream privileges include the User holds any role on the product
owning the object rule. As a result, there is a security issue where certain users are
able to download and upload files from any project in the product including those to which
they should not have access. To correct this, you must remove the User holds any role
on the product owning the object rule from the grant rules for the Update Files
from Project/Stream and Deliver Files into Project/Stream privileges.
Privilege Reference
This section describes all of the different privileges, and lists the rules that can apply to
each. For a detailed description of each rule, see "Privilege Rules above".
Administration privileges apply to all products in the base database. The other, product
level privileges only apply to your currently selected product.
Note About Default Grant Rules for Download Files from Project Privilege
When you create a new base database, the default grant rules for the Update Files from
Project/Stream and Deliver Files into Project/Stream privileges include the "User holds
any role on the product owning the object" rule. As a result, there is a security issue
where certain users are able to download and upload files from any project in the product
including those to which they should not have access. To correct this, you must remove
the "User holds any role on the product owning the object" rule from the grant rules for
"Update Files from Project/Stream" and "Deliver Files into Project/Stream" privileges.
Administration Privileges
Administration privileges apply to all products in the base database.
Name ID Description
Create ADMIN_CREATE_DEPLOY_AREA This privilege allows you to create a
Deployment Areas deployment area.
Create Library ADMIN_CREATE_LIBCACHE_AREA This privilege allows you to create a
Cache Areas library cache area.
Create Products ADMIN_CREATE_PRODUCT This privilege allows you to create
products.
Create Work Areas ADMIN_CREATE_WORK_AREA This privilege allows you to create a
work area.
Delete ADMIN_DELETE_DEPLOY_AREA This privilege allows you to delete a
Deployment Areas deployment area.
Delete Library ADMIN_DELETE_LIBCACHE_AREA This privilege allows you to delete a
Cache Areas library cache area.
Delete Work Areas ADMIN_DELETE_WORK_AREA This privilege allows you to delete a
work area.
Manage and View ADMIN_OTHER_PENDLIST This privilege allows you to view and
Other Users' Lists manage other users' lists.
Manage Baseline ADMIN_TEMPLATEMAN This privilege allows you to manage
and Release baseline and release template
Templates definitions.
Name ID Description
Manage Build ADMIN_BUILDMAN This privilege allows you to manage
Configurations build configurations.
Manage Customer ADMIN_CUSTDEFMAN This privilege allows you to manage
Definitions customer definitions.
Manage Email ADMIN_EMAILNOTIFY_SUBSCRIBE This privilege allows you to manage
Notifications e-mail notifications.
Manage File ADMIN_FORMATMAN This privilege allows you to manage
Format Definitions file formats for items and requests.
Manage Item ADMIN_ITEMRELSMAN This privilege allows you to manage
Relationship item relationships.
Names
Manage Lifecycles ADMIN_LIFECYCLEMAN This privilege allows you to manage
lifecycle definitions.
Manage Mover ADMIN_MOVER_DEPLOY This privilege allows you to manage
Deployment deployments via Serena Mover.
Definitions
Manage Network ADMIN_NETWORK This privilege allows you to manage
Definitions the Dimensions network definitions.
Manage Privileges ADMIN_PRIVILEGEMAN This privilege allows you to grant
admin and non-admin privileges.
Manage Public ADMIN_PUBLICQUERIES This privilege allows you to manage
Queries public based queries.
Manage ADMIN_REPL This privilege allows you to manage
Replication Replication configuration definitions,
Configurations run replicator, and also run pdiff
Manage Role ADMIN_ROLEMAN This privilege allows you to manage
Definitions role definitions.
Manage Upload ADMIN_UPLOADMAN This privilege allows you to manage
Rules upload and item/request format
definitions.
Manage User ADMIN_UI_PROFILES This privilege allows you to manage
Interface Profiles user interface profiles.
Manage User ADMIN_REPORTMAN This privilege allows you to manage
Report user report configurations and
Configurations definitions.
Manage Users and ADMIN_USERMAN This privilege allows you to manage
Group Definitions users and groups for a database.
Manage Version ADMIN_BRANCHMAN This privilege allows you to manage
Branch Definitions the version branches in the database.
Publishing ADMIN_PUBLISHPREFS This privilege allows you to publish a
Preferences set of default preferences.
Run Admin ADMIN_RUN_REPORT This privilege allows you to run admin
Reports reports and other reports.
Update ADMIN_UPDATE_DEPLOY_AREA This privilege allows you to update
Deployment Area deployment area properties such as
Properties hostname, area owner user and
password.
Name ID Description
Update Library ADMIN_UPDATE_LIBCACHE_AREA This privilege allows you to update
Cache Area library cache area properties such as
Properties hostname, area owner user and
password.
Update Work Area ADMIN_UPDATE_WORK_AREA This privilege allows you to update
Properties work area properties such as
hostname, area owner user and
password.
Name ID Description
Update BASELINE_UPDATE This privilege allows you to edit
baseline attributes.
Update Files from BASELINE_DOWNLOAD This privilege allows you to update
Baseline files in your work area from a
baseline.
Name ID Description
Relate Item to ITEM_RELATE_ITEM This privilege allows you to relate/unrelate
Item items to/from items.
Rename ITEM_RENAME This privilege allows you to rename item
identifiers.
Revise Item ITEM_UPDATECONTENT This privilege allows you to check out, check
Content in and merge items.
Rollback from ITEM_ROLLBACK This privilege allows you to rollback items
Areas from areas. See "Note About Roll Back
Privileges" on page 364.
Suspend ITEM_SUSPEND This privilege allows you to suspend items.
Update ITEM_UPDATE This privilege allows you to edit the
attributes of an item.
Name ID Description
Import Request PROJECT_IMPORT_REQUEST This privilege allows you to import a
into Project request into a project.
Lock PROJECT_LOCK This privilege allows you to lock and
unlock a project or stream.
Populate an Area PROJECT_POPULATE_AREAS This privilege allows you to populate
from a Project/ an area from a project or stream.
Stream
Relate Requests to PROJECT_RELATE_REQUEST This privilege allows you to relate/
Project/Stream unrelate requests to/from a project or
stream.
Remove Item PROJECT_REMOVEFILE This privilege allows you to remove
revisions from item revisions from a project.
Project
Rename PROJECT_RENAME This privilege allows you to rename a
project or stream.
Rename PROJECT_RENAME_DIR This privilege allows you to rename or
Directories move directories.
Rename Item PROJECT_RENAME_FILE This privilege allows you to rename
Filenames project filenames.
Update PROJECT_UPDATE This privilege allows you to update the
attributes of a project or stream.
Deliver Files into PROJECT_UPLOAD This privilege allows you to deliver files
Project/Stream from your work area into a project or
stream.
Name ID Description
Perform REQUEST_RREPLIC_OPS This privilege allows you to perform
Replication replication specific operations for
Operations requests.
Prime REQUEST_PRIME This privilege allows you to prime
requests.
Promote to Any REQUEST_PROMOTE_ANYSTAGE This privilege allows you to promote
Strage requests to the any promotion stage in
the lifecycle
Promote to Next REQUEST_PROMOTE_NEXSTAGE This privilege allows you to promote
Strage requests to the next promotion stage in
the lifecycle
Relate Request to REQUEST_RELATE_BASELINE This privilege allows you to relate/
Baseline unrelate a request to/from baselines.
Relate Request to REQUEST_RELATE_PART This privilege allows you to relate/
Design Part unrelate a request to/from design parts.
Relate Request to REQUEST_RELATE_ITEM This privilege allows you to relate/
Item unrelate a request to/from items.
Relate Request to REQUEST_RELATE_REQUEST This privilege allows you to relate/
Request unrelate a request to/from other
requests.
Rollback from REQUEST_ROLLBACK Note: This privilege does not have any
Areas effect, and should not be used.
Update REQUEST_UPDATE_ATTACH This privilege allows you to add/remove
Attachments attachments.
Update Request REQUEST_UPDATE This privilege allows you to edit
attributes and add/remove action
descriptions.
logging in 70 F
Dimensions CM
documentation set 16 file class 236
Dimensions object class values 236
object definitions 135 file format class 237
Dimensions roles 60 file format value
Dimensions upload rules 224 binary 236
directory path Macintosh 236
item library 176 Windows 2000/NT 237
DM_ORDER_ATTR_RULES_BY_ROLE 33 filter
DM_USE_OLD_CRB 33 lifecycle editor 193, 259
documentation set 16 filtering
dormant users, reactivating 89 data formats in main window 241
role assignments 100
*FINAL 207
E format templates
items 304
edit lifecycle dialog box requests 304
transitions area 198, 262 FROZEN phase 40
editing
assigned lifecycle 155
attribute 152 G
attribute rule 202
CM rules 173 general section
data formats 242 object types 146
design parts 121 global lifecycle image
IDM tool instance 275 deleting 262
lifecycle 191, 257 importing 261
lifecycles 191 global projects 25
object type 147 groups
preservation policies 232 adding 92, 93
preservation rules 233
prime mapping 165
products 128
project/stream options 278
H
relationship name 157
HELD phase 39
roles 96
transitions 199, 264 *HIGHEST 207
user interface profiles 113 host node for item library 175
valid relationship 163
valid sets 132
valid version branch names 248 I
electronic signature 34, 196
email IANA 237
user's address for email notifications 89 IANA media types 237
e-mail notification 58 IDEs
defining rules for 106 upload rules 224
request IDM tool
actioned 144 definition 272
e-mail templates IDM tool instance
multi-value attributes 358 creating 274
EQS, see specified state only editing 275
excluding files from Dimensions 227 setting default 273
exporting implicit-state
template file 170 default rule 329
of baseline template 328
implicit-state title
*All revisions 328
*Latest edit revision 328
WORK 39 R
platform support 17
preservation policies reactivating dormant users 89
adding project stages 234 REJECTED phase 40
copying 232 relating
deleting 232 object types to lifecycles 187
deleting project stages 234 relationship names 155
editing 232 creating 157
preservation rules deleting 158
adding 233 editing 157
deleting 233 relationship names section
editing 233 item types 155
primary capability (roles) 59 request types 156
prime mappings relationships 34
creating 165 Affected By (item/request) 37
deleting 166 breakdown 23
editing 165 Created From (item/item) 36
request 164 Dependent (request/request) 36
prime mappings section In Response To (item/request) 37
object type definitions 164 Information (item/request) 37
printing manuals 17 Information (request/request) 36
process model item/design part 35
attributes 29 item/item 35
change management rules 38 item/request 37
components 22 Made Into (item/item) 35
cross-product baseline 332 Made Of (item/item) 35
design parts 22 Owned (item/design part) 35
lifecycles 27 usage 23
objects 24 Used (item/design part) 35
privilege rules 28 release baseline 206
relationships 34 release configuration 339
Product Manager 60 release template
products copying 217, 218
copying 128 creating 217
defining 127 defined 209
deleting 128 deleting 219
editing 128 selection criteria 209
project setting up 338
management perspective 22 subdirectory 209
technical perspective 22 releases
project directories 25 definition 26
Project Manager 60 renaming
project root directories 26 state 196, 261
project type request baseline template
options 144 constraints 337
project/stream options request baseline templates 336
definition 277 request phases
editing 278 AN+WORK 40
projects CLOSED 40
and parallel development 25 FROZEN 40
definition 25 OFF NORM 40
directories 25 REJECTED 40
global 25 WORK 39
root directories 26 request type
properties options 143
lifecycle editing 188 requests
protection attribute history 144
item library 176 attributes 29
proxy users 84 CM rules section 172
V
valid relationship 158
assigning 162
editing 163
maximum status attribute 158
minimum status attribute 158
valid relationships section
items 160
requests 161
valid sets
associating with attributes 132
copying 132
defining 131
definition 30
deleting 132
editing 132
variables
multi-valued 309
single-valued 308
version branch names 245
defining 247
definition 246
deleting 248
editing 248
viewing
CM phase usage 174
lifecycle image 189
W
Windows 2000/NT file format value 237
Windows 2000/NT system libraries 176
work packages 25
WORK phase 39
Workset Manager 60
Z
z/OS system libraries 177