im createtype
creates an issue type
Synopsis
im createtype [--addWordTemplate=name=templateName,path=templatePath[,description=description][,defaultEdit]] [--testResult] [--removeWordTemplate=value] [--editPresentation=value [--printPresentation=value [--printReport=report [--viewPresentation=value [--name=value] [--image=[none|<path>] [--description=value] [--[no]enableRevision] [--majorRevisionRule=rulename] [--minorRevisionRule=rulename] [--copyMajorRevisionRule=type] [--copyMinorRevisionRule=type] [--majorRevisionRuleFile=filename] [--minorRevisionRuleFile=filename] [--position=<number>] [--[no]allowChangePackages] [--createCPPolicy=value] [--[no]duplicateDetectionMandatory] [--duplicateDetectionSearchField=field] [--documentClass=[none|segment|node|shareditem]] [--associatedType=type] [--significantFields=field,field,...] [--defaultReferenceMode=[Reuse|Share]] [--versionEditFields=field,field,...] [--visibleFields=field:group,group,...[;...]] [--notificationFields=field,field,...] [--stateTransitions=state:state:group|dynamic group,group|dynamic group,...[;...]] [--addLabelRule=rule] [--moveLabelRule=rule] [--copyMoveLabelRule=type] [--moveLabelRuleFile=filename] [--properties=name:value:description[;...]] [--addLabelRuleFile=value] [--branchRule=rule] [--branchRuleFile=value] [--branchFields=field,field,...] [--copyAddLabelRule=type] [--copyBranchRule=type] [--copyCopyTreeRule=type] [--copyDeleteLabelRule=type] [--copyTreeRule=type] [--copyFields=field,field,...] [--copyTreeRuleFile=value] [--deleteLabelRule=type] [--defaultReferenceMode=[reuse|share]] [--deleteLabelRuleFile=filename] [--[no]enableDeleteItem] [--deleteItemRule=value] [--deleteItemRuleFile=value] [--copyDeleteItemRule=type] [--[no]enableBranch] [--[no]enableCopyTree] [--[no]enableLabel] [--testRole=[none|testSession|testCase|testStep|testSuite]] [--[no]enableTestSteps] [--[no]enableTestResultRelationship] [--testCaseResultFields=field,field,...] [--testSessionDateField=value] [--modifyTestResultPolicy=value] [--[no]groupDocument] [--editabilityRule=rule] [--editabilityRuleFile=filename] [--copyEditabilityRule=type] [--mandatoryFields=state:field,field,...[;...]] [--addFieldRelationship=constraint] [--fieldRelationships=constraint[;constraint]] [--removefieldRelationship=constraint] [--fieldRelationshipsFile=value] [--[no]showHistory] [--[no]showWorkflow] [--phaseField=field] [--[no]enableProjectBacking] [--[no]enableTimeTracking] [--permittedAdministrators=u=user1,user2,...;g=group1,group2] [--permittedGroups=group,group,...] [--[no]allowDocumentLocks] [--documentLockPolicy=value] [--documentUnlockGroup=group] [--[no]allowAdditionalLockFields] [--additionalLockFieldsRule=rule] [--additionalLockFieldsRuleFile=filename] [--copyAdditionalLockFieldsRule=type] [--additionalSegmentLockFields=field,field,...] [--additionalContentLockFields=field,field,...] [--[no]lockingRequired] [--lockingRequiredRule=rule] [--lockingRequiredRuleFile=filename] [--copyLockingRequiredRule=type] [--user=name] [--hostname=server] [--password=password] [--port=number] [(-?|--usage)] [(-F file|--selectionFile=file)] [(-N|--no)] [(-Y|--yes)] [--[no]batch] [--cwd=directory] [--forceConfirm=[yes|no]] [-g|--gui] [--quiet] [--settingsUI=[gui|default]] [--hiddenMenus=[None|CreateItem|CreateRelatedItem|CreateDocument|InsertContent]] [--status=[none|gui|default]] [--defaultFieldsForWebUI=field,field,...]
Description
im createtype creates an issue type. For example:
im createtype --name=Defect --description="Captures software defects" --allowAttachments --allowChangePackages
creates the Defect type with a description, allowing attachments and change packages.
|
|
A type can contain a maximum of 1000 fields. Exceeding the maximum number of fields results in exception errors when creating, editing, or viewing the issue type in the GUI.
|
Options
This command takes the universal options available to all
im commands, as well as some general options. See the
options reference page for descriptions.
• --testResult
specifies whether the type is used for test results only. For more information on using types for test results, see the Windchill RV&S Help Center.
• --editPresentation=value
specifies the presentation template to use when editing this type. Presentation templates allow you to customize issue presentation. For more information on presentation templates, see the Windchill RV&S Help Center.
• --printPresentation=value
specifies the presentation template to use when printing this type. Presentation templates allow you to customize issue presentation. For more information on presentation templates, see the Windchill RV&S Help Center.
• --printReport=report
specifies the administrator report that will provide the structure and format when a user prints a document using > from the GUI. This must be specified with --documentClass=segment.
• --viewPresentation=value
specifies the presentation template to use when viewing this type. Presentation templates allow you to customize issue presentation. For more information on presentation templates, see the Windchill RV&S Help Center.
• --name=value
specifies the name of the type. Names can be a maximum of 100 characters and cannot contain square brackets. This option is mandatory.
• --image=[none|<path>]
specifies whether an image appears for the type.
--image=none does not specify an image for the type.
--image=<path> specifies the path and name of a custom image for the type, for example, c:\images\type_icon.gif.
|
|
Images must be GIF or JPEG format, and no larger than 16 by 24 pixels.
|
• --description=value
specifies a description of the type.
• --[no]enableRevision
specifies whether to enable item revisioning for the specified item type or enable document versioning for the specified document model type. For more information on item revisioning or document versioning, see the Windchill RV&S Help Center.
• --majorRevisionRule=rulename
specifies a rule that must be true for the item type (used with item revisioning) or document model type (used with document versioning) in order to increment the major revision. For example, if the major rule is
Type=Requirement, then only items of type Requirement may have major revisions incremented. For the rule syntax, see Specifying Rules on the
options reference page.
• --minorRevisionRule=rulename
specifies a rule that must be true for the item type (used with item revisioning) or document model type (used with document versioning) in order to increment the minor revision. For example, if the minor rule is
State=Open, then only items in an open state may have minor revisions incremented. For the rule syntax, see Specifying Rules on the
options reference page.
• --copyMajorRevisionRule=type
copies the major revision rule of an existing item type (used with item revisioning) or document model type (used with document versioning) to the one being created.
• --copyMinorRevisionRule=type
copies the minor revision rule of an existing item type (used with item revisioning) or document model type (used with document versioning) to the one being created.
• --majorRevisionRuleFile=filename
specifies a file that contains the major revision rule for the specified item type (used with item revisioning) or document model type (used with document versioning). For the file format, see Specifying Rules on the
options reference page.
• --minorRevisionRuleFile=filename
specifies a file that contains the minor revision rule for the specified item type (used with item revisioning) or document model type (used with document versioning). For the file format, see Specifying Rules on the
options reference page.
• --documentClass=[none|segment|node|shareditem]
allows you to specify a document class on a type. Each document domain requires a segment, a node type associated with the segment, and a shared item type associated with the node type. Each document instance requires the segment root and a set of nodes. The options are as follows:
◦ none specifies that this item type is not used in documents. The default for all non-document types.
◦ segment specifies that this type is used in the segment root. For example, you need to specify segment if you are creating a document domain.
◦ node specifies that this type is used in nodes (content). Node correlates to the content (i.e. Requirement, Input, Test, Specification) item type. To create content, you need a node and a corresponding shared item. Therefore, you would create two types: one with documentClass=node, and the other with documentClass=shared item. Each node in a document is a reference to a shared item or a subsegment, and all three types expose arbitrary fields. Nodes also expose FVA fields from the shared item.
◦ shared item specifies that this type is a shared item. Shared items should be associated with a corresponding node type (content). Each node class on a type requires an associated shared item.
Example:
im createtype --name=Document --description="Requirement Document"
--documentClass="segment" --associatedType="Requirement(node name)"
creates a segment with an associate node type called Requirement.
• --[no]duplicateDetectionMandatory
makes it mandatory for users to view potential duplicates before they create a new item.
• --duplicateDetectionSearchField=field
specifies the name of the short text field to search when using duplicate detection. Setting an empty field means that duplicate detection will not be available to users. The short text field cannot be a computational field or Field Value Attribute to a short text field. Before enabling duplicate detection, the selected short text field must be visible on the type. In addition, to use duplicate detection searches on a short text field, the created field must have text search indexing enabled. When searching for potential duplicates, the default number of results is 20 items.
• --testRole=[none|testSession|testCase|testStep|testSuite]
allows you to specify the test management role for the type. The options are as follows:
◦ none specifies that this item type does not a have a specific test management role. However, it can still be related to test results using the --[no]enableTestResultRelationship option.
◦ testSession specifies that this type is a test session. A test session is a concrete run or execution of a group of test cases. If a type is a test session, also specify modifyTestResultPolicy.
◦ testCase specifies that this type is a test case. A test case describes the test conditions and provides a container for adding test results from the test session. A test case must have the --documentClass option set to node. If a type is a test case, also specify --[no]enableTestSteps and --testCaseResultFields.
◦ testStep specifies that this type is a test step. A test step is a specific testing operation performed as part of executing a test case.
◦ testSuite specifies that this type is a test suite. A test suite is a grouping of test cases. A test case must have the --documentClass option set to segment.
• --associatedType=type
specifies an associated type for segments and nodes. If the document class is segment, the associated type is of type node. If it is node, the type is of shared item.
• --defaultReferenceMode=[Reuse|Share]
specifies the reference mode to apply to nodes after they are branched. Reuse points to the same shared item until the original node changes and a new shared item is created.Share points to the same shared item as the original branched node. Editability will not be allowed on shared fields; this mode only allows observation of the changes made on the other item.
• --significantFields=field,field,...
allows you to specify additional fields by type that, when edited, results in an update to the content revision. This is reflected in a change to the revision date in the item history. Each type has default associated significant edit fields.
• --position=<number>
specifies the position in the list of types.
• --addLabelRule=rule
specifies the rules for when users are permitted to add a label rule. For the rule syntax, see Specifying Rules on the
options reference page.
• --addLabelRuleFile=filename
specifies a file that contains the add label rule set for the specified issue type. For the file format, see Specifying Rules on the
options reference page.
• --moveLabelRule=rule
specifies the rules for when users are permitted to move a label. For the rule syntax, see Specifying Rules on the
options reference page.
• --copyMoveLabelRule=type
specifies the type from which to copy rules for when users are permitted to move a label. For the rule syntax, see Specifying Rules on the
options reference page.
• --moveLabelRuleFile=filename
specifies a file that contains the move label rule set for the specified issue type. For the file format, see Specifying Rules on the
options reference page.
• --branchRule=rule
specifies the rules for branching by users. For the rule syntax, see Specifying Rules on the
options reference page.
|
|
Users or groups do not require editability of the issue or any given field to be able to branch an issue; however, they must have project or type visibility to branch an issue. If a user does not have visibility to a given field during a branch operation, the field will be copied unchanged.
|
• --branchRuleFile=filename
specifies a file that contains the branch rule set for the specified issue type. For the file content format, see Specifying Rules on the
options reference page.
• --branchFields=field,field,...
specifies the list of fields to make visible on the Branches tab for viewing item branches.
|
|
The branched fields that can be configured are only visible fields on the item type. This means that field visibility permission is checked when adding a branched field. The --branchFields option can be used with --visibleFields=field:group,group,...[;...] for each command.
|
• --copyAddLabelRule=type
specifies the rules for when users or groups are permitted to copy an add label rule.
• --copyBranchRule=type
specifies the rules for when users are permitted to copy a branch rule.
• --copyCopyTreeRule=type
specifies the rules for when users or groups have the ability to copy the copy tree rule for the specified issue type.
• --copyDeleteLabelRule=type
copies the delete label rule of an existing type to the one being edited.
• --[no]enableBranch
specifies whether issues of this type can be branched. For more information on branching, see the Windchill RV&S Help Center.
• --[no]enableCopyTree
specifies whether users or groups can copy a tree of issues belonging to the hierarchy for this type.
• --[no]enableLabel
specifies whether users or groups can add labels to issues of this type.
• --copyTreeRule=rule
copies the tree rule of an existing type to the one being created.
• --copyTreeRuleFile=value
specifies a file that contains the copy tree rule set for the specified issue type.
• --deleteLabelRule=type
specifies the rule for when users or groups can delete label rules.
• --deleteLabelRuleFile=value
specifies a file that contains the delete label rule set for the specified issue type.
• --[no]enableDeleteItem
specifies whether items of the specified type can be deleted. If items of the specified type can be deleted, a rule set must specified with --deleteItemRule=value or --deleteItemRuleFile=value.
• --deleteItemRule=value
allows specific users or groups the ability to delete items of the specified item type. To change the rule on who can delete items, users or groups require the ModifyDeleteItemRule permission.
|
|
Important: The ModifyDeleteItemRule permission differs from the DeleteItem permission, which allows users or groups to delete items of any type without a defined rule. To define strict item deletion rules in your organization, PTC recommends defining a delete item rule and assigning the ModifyDeleteItemRule permission to the appropriate users and groups.
|
• --deleteItemRuleFile=value
specifies a file that contains the rule set for deleting items of the specified item type.
• --copyDeleteItemRule=type
specifies a type to copy an existing delete rule set from.
• --[no]allowChangePackages
specifies whether configuration management change packages are permitted for the type.
• --[no]groupDocument
specifies whether items of the specified type will be used to group content. For group documents, the --documentClass option must be segment.
• --[no]enableTestSteps
specifies whether the test case type can use test steps. A test step is a specific test for a test case. A test case can contain an ordered list of steps to follow in order to complete the test. Test steps can be shared across test cases.
• --[no]enableTestResultRelationship
specifies whether the type can be related to test results. For example, defects for failed test results.
• --testCaseResultFields=field,field,...
specifies fields from the test case type that will display in the Test Result Details view.
• --modifyTestResultPolicy=value
specifies which users and/or groups are allowed to modify test results for the test session item type. The default value for the policy is userField=assignedUser, that is, only users who are assigned to the test session are permitted to create test results. Valid values are userField=<field>, groupField=<field>, anyone, groups=group1,group2,....
• --createCPPolicy=value
specifies which users and/or groups are allowed to create change packages against issues of this type. The default value for the policy is userField=assignedUser, that is, only users who are assigned to issues within that type are permitted to create change packages. Valid values are userField=<field>, groupField=<field>, anyone, groups=group1,group2,....
• --versionEditFields=field,field,...
specifies the fields that users will be able to edit on document and content versions. Fields that are included in the --significantFields list may not also be included in --versionEditFields list. Conversely, fields that are included in the --versionEditFields list may not also be included in --significantFields list.
For document and content versions, you can only allow editing on some field types and some built-in fields are not allowed. For the list of supported field types and built-in field restrictions, see “Significant Edit Fields” in the Windchill RV&S Help Center.
• --visibleFields=field:group,group,... [;...]
specifies which groups have visibility for which fields. By default, the everyone group is specified for each field you specify. All previous values are replaced with specified values.
|
|
Special fields are always visible, even if they are not specified.
|
• --notificationFields=field,field,...
specifies notification fields for including in every email notification related to this type.
|
|
SI project and attachment fields cannot be specified.
|
• --copyFields=field,field,...
specifies the list of fields to be copied by default for items of this type. This setting overrides --copyCommonFields if set. Users can override these default fields by adding and removing any fields that they can view and edit.
• --stateTransitions=state:state:group|dynamic group,group|dynamic group,...[;...]
specifies a state transition from one state to another, and the groups/dynamic groups permitted to make that state transition. At least one group/dynamic group must be specified for each transition.
• --properties=name:value:description[;...]
defines type properties. Type properties provide custom code (such as triggers and API) with attributes to read and act on based on their values. The following can be specified for each property:
◦ name specifies the name of the property.
◦ value specifies the value for the property.
◦ description specifies an optional description for the property.
• --editabilityRule=rule
specifies the rules for when users are permitted to edit the type. For the rule syntax, see Specifying Rules on the
options reference page.
|
|
• To specify a date and time for a date field, use the MM/dd/yyyy h:mm:ss [AM|PM] format. You can specify a time only if the date field is configured to display the time. To specify the current date and a time of 00:00:00 (midnight) for a date field, type today. This option can be specified only if the date field is configured to display the date. To specify the current date and time for a date field, type now. This option can be specified only if the date field is configured to display the date and time. To specify an empty value for the date field, type none.
• When specifying a user, you can choose yourself by specifying "me". "me" is a symbolic user which refers to the currently logged in user. For example, you could create an editability rule that specifies a Project type issue can be edited if the currently logged in user is one of the users defined in the multi-valued Stakeholders field.
• SI project and attachment fields cannot be specified.
• If a group name contains blank spaces, a second pair of quotes around “”group name”” is required. For example:
im editfield --hostname=server --port=7001 --editabilityRule="((user is a member of "Project Management" or (user is a member of ""Project Management""))" fieldname
|
• --editabilityRuleFile=filename
specifies a file that contains the issue editability rule set for the specified type. For the rule syntax, see Specifying Rules on the
options reference page.
• --copyEditabilityRule=type
copies the issue editability rule of an existing type to the new one being created.
• --mandatoryFields=state:field,field,...[;...]
specifies mandatory fields for a state in the type's workflow. All previously specified mandatory fields are replaced with the new values. Mandatory fields can also be set on type constraints. For more information on constraints, see the Windchill RV&S Help Center.
• --addFieldRelationship=constraint
specifies a single constraint (field relationship) to be added to a type.
• --removeFieldRelationship=constraint
specifies a single constraint (field relationship) to be removed from a type.
• --fieldRelationships=constraint[;constraint]
specifies constraints between fields. All previously existing constraints on this type are replaced with the new constraints specified here. The syntax specified below also applies for the --addFieldRelationship and --removeFieldRelationship options.
There are four constraint methods: Basic, Field Relationship, Rule, and Item Backed Pick List (IBPL). For more information on constraints and constraint methods, see the Windchill RV&S Help Center.
|
|
Important: If you are creating or copying a type, you cannot reference the name of that new type when creating a basic constraint. Other rule-based constraints, such as Rule and IBPL, can be created; however, errors may occur if you attempt to create a constraint based on a rule that includes the new type name, for example, (Field[Type]=new type name)
where constraint is one of:
a Basic or Field Relationship constraint:
sourceField=sourceValue1[,sourceValue2,...]:targetValue [:[all][,mandatory][,errInvalidated=invalidMessage][,errMandatory=mandatoryMessage][,description=descriptionText]]
a Rule constraint:
constraintrule=(rule) :targetValue[:[all][,mandatory][,errInvalidated=invalidMessage][,errMandatory=mandatoryMessage][,description=descriptionText]]
an IBPL constraint:
rule=(ibplRule):ibplField [:[mandatory][,errInvalidated=invalidMessage][,errMandatory=mandatoryMessage][,description=descriptionText]]
and where sourceField is any field with predefined values (Pick, User, Group, IBPL, Boolean, Project, State, Phase, Type). For the basic constraint method, sourceField must be the type you are editing, and the source value must be the specified type.
and where targetValue is:
targetField=[value1][,value2,...] where targetField is a field of type other than User/Group.
or
targetField=[value1][,value2,...][,hasProjectPermission] where targetField is a field of type Group.
or
targetField=[value1][,value2,...][,hasProjectPermission][memberOf(dynamicGroup1[,dynamicGroup2,...])][valueOf(group)]
where targetField is a field of type User.
targetField can be any field that is visible on the type and that is not the sourceField. Only the following fields can have values specified: User, Group, Pick, State, Project, IBPL, Logical. All other fields (such as Attachment, Integer, Short Text, etc...) can only be made mandatory.
Specifying values (value1, value2, etc...) is optional; however, if not specified, the all and mandatory options must be used to indicate that the field is mandatory and all values are acceptable.
|
|
|
For all targetField types, if a mandatory option is specified, then at least one value (value1,value2, ...) must be specified, or the all option must be present.
|
hasProjectPermission constrains the values of the field to only those users or groups that have permissions for the item's project. This option cannot be specified with any values (value1, value2...), or with memberOf or valueOf options.
memberOf constrains the values of the field only to those users that are a members of the listed dynamic groups ((dynamicGroup1, dynamicGroup2, ...). Note that the everyone group can also be used as a value for the dynamic groups. This option cannot be specified with any values (value1, value2...), or with hasProjectPermission or valueOf options.
valueOf constrains the values of the field to only the specified group. This option cannot be specified with any values (value1, value2...), or with hasProjectPermission or memberOf options.
and where
rule is a specified rule. For the rule syntax, see "Specifying Rules" on the
options reference page.
|
|
• Attachment fields, text fields, relationships fields, and dynamic computed fields cannot be specified.
• If one field is a date type field, then the other field must also be a date type field.
and where ibplRule is a specified IPBL rule. For the rule syntax, see "Specifying Rules" on the options reference page. |
|
|
The IBPL rule can be made up of:
• sub-rules on the field values of the items backing the IBPL target. In the CLI, add an apostrophe (') at the end of the field to indicate the Target Field option in the GUI.
• sub-rules on the item being edited. If no apostrophe is added, then the 'Editing Item Value' GUI option is selected.
In addition:
• Attachment fields, text fields, relationships fields, and dynamic computed fields cannot be specified.
• If one field is a date type field, then the other field must also be a date type field.
and where ibplField is an IBPL field that is visible on a type.
and where invalidMessage is any string up to 2000 characters.
and where mandatoryMessage is any string up to 2000 characters.
and where descriptionText is any string up to 200 characters.
|
Examples:
Basic Constraint Method:Type=AdminRequest:"Assigned User"=memberOf(manager,administrator):mandatory,errMandatory="The {ConstrainedField} cannot be empty."
Specifies that all items of the AdminRequest type must be assigned to a user who is either in the manager or an administrator group, and that the "Assigned User" field is mandatory.
Field Relationship Constraint Method:
Importance=High,Critical:Escalated=True:mandatory,description="Ensure that the Incident is escalated if Importance is either High or Critical".
Specifies that an incident is escalated if Importance is either High or Critical.
Rule Constraint Method:
constraintrule=(field[importance]>"8"):"Assigned User"=valueOf(manager):mandatory
Specifies that if the item is very important (importance > 8), then assign the item to a manager.
IBPL Constraint Method:
rule=(field["State"] = "Prioritized"):Priority
Specifies that if the state is Prioritized, then the Priority IBPL is visible.
rule=(field'["Graduated"] = true):Students
Filters the list of students such that the only values displayed are those where the student's backing item has Graduated set to true.
|
|
You can specify the options for --fieldRelationships, --addFieldRelationship, and --removeFieldRelationship at the same time. If all three options are specified at the same time, the constraints on the type are modified in the following order:
1. --fieldRelationships is executed first and all constraints are replaced by the ones specified here.
2. --removeFieldRelationship is executed next and the specified constraints are removed from the ones specified in the --fieldRelationships option.
3. --addFieldRelationship is executed last and the specified constraints are added to the type.
|
The options for --removeFieldRelationship and --addFieldRelationship can be specified multiple times on the command.
|
|
If you need to specify a large number of constraints (field relationships), use the --fieldRelationshipsFile option.
|
• --fieldRelationshipsFile=value
specifies the name of the file containing the constraint. The file should use the same format as the --fieldRelationships option, with all constraints on the same line and separated by semi-colons. For information on constraints, see the Windchill RV&S Help Center.
|
|
If you specify both --fieldRelationships and --fieldRelationshipsFile, only --fieldRelationships is used.
|
• --[no]showHistory
specifies whether to display the item history for all items of the selected type. When you set --noshowHistory for an existing type, the item history is always hidden from users when they are viewing or editing items of that type. The setting applies in all Windchill RV&S Client interfaces. For example, in the Windchill RV&S Client GUI and Web interface, when you set the --noshowHistory option, the History tab is no longer displayed for items of the selected type. By default, the item history is displayed for newly created types.
• --[no]showWorkflow
specifies whether to display the Workflowtab to the user in the Create Issue view, Edit Issue view, and Issue Detail view. The Workflow tab contains a read-only display of the issue type workflow to the user. Users in the Web interfaces do not have a user preference to override the display of the Workflow tab. Users launching the GUI view from the CLI can override the display of the Workflow tab on a per command basis, if workflow for that type is enabled.
• --phaseField=field
specifies the phase field to display in the Workflow tab of the Create Issue view, Edit Issue view, and Issue Detail view. Only a phase field that is specified in the --visibleFields option may be specified. This option must be specified with the --showWorkflow option.
• --[no]enableProjectBacking
Enables the type to back a project, allowing you to create a link between an issue of this type and a project in the Project field. By creating a Project issue type and specifying this option, then creating a Project issue and linking it to a specific project (using the im createissue command), the power and workflow of projects as issues becomes available. Important metadata and metrics can be recorded in the Project issue, for example, the assigned Project Manager, estimated and actual budgets (using computed fields), and important milestone dates. Linking a Project issue to a project also reduces possible confusion about the details of projects in your database.
|
|
• A link between a Project issue and a project is optional.
• If you enable this option, creating issues of this type and linking them to projects is useful only to certain users. You may want to prevent most users from being able to create issues of this type, for example, you can allow only users in the ProjectManagers group to create Project issues. To restrict type visibility, see the --permittedGroups option.
• Projects and Project issues can be used independent of one another; you do not have to create a Project type to use the Project field.
• Multiple types can back projects; however, only one issue may back a given project.
• To enable this option, you must be an administrator for the specified type. This option can be disabled at any time.
• This option cannot be specified unless the Project field is specified as a visible field for this type.
• To create the issue that backs a project, you must be an administrator for the specified project and belong to a group that has permission to create issues of that type.
• When you create an issue to back a project, Windchill RV&S warns you if there is more than one type that can back a project, displaying a list of types that have this option enabled and that you have “view” and “modify” permissions for. Specify the type that you want to back the project.
• For Admin Staging, you cannot stage issues. Issues that back projects created on a Staging server will not be staged; you must re-create the issues that back projects on the production server. Rules, queries, or computed fields that explicitly mention the issue number that backs a project will not work after they have been transferred from the staging server to the production server.
|
• --[no]enableTimeTracking
Allows one or more users to allocate time spent working on issues of this type. When enabled, users can specify time entries when they edit an issue. In addition, a Time Entries tab is available when you view an issue of this type. You can use time entries to develop metrics (in the form of queries, charts, and reports) that measure the amount of effort spent on projects.
|
|
• To create, edit, and delete time entries on behalf of other users, the TimeTrackingAdmin ACL permission is required.
• The ability to create, edit, and delete time entries is governed by state-based capabilities. For more information, see the im createstate and im editstate commands.
|
• --permittedAdministrators=u=user1,user2,...;g=group1,group2,...
specifies a comma delimited list of users and/or groups that can administer this type. Windchill RV&S Type Administrators are allowed to edit and view types. Type Administrators are not allowed to assign themselves as administrators to any other types, or to edit types that they don't administer. A Type Administrator can create fields, but can only edit fields that are referenced by a type they administer. For more information, see the Windchill RV&S Help Center.
• --permittedGroups=group,group,...
specifies a comma delimited list of groups that have visibility for this type.
• --addWordTemplate=name=templateName,path=templatePath[,description=description][,defaultEdit]
specifies a template to add to the type for users to use when editing items in Microsoft® Word. For information on using Microsoft® Word templates, see the Windchill RV&S Help Center.
◦ name
specifies the name of the template. The name is visible to users if more than one template is available for selection.
◦ path
specifies the path of the template to add to the type. The file must be DOTX format.
◦ description
specifies an optional description for the template.
◦ defaultEdit
specifies to use the template as the default template for users editing an item or document in Word. Specifying this option pre-selects the template for the user. However, the user may still select a different template if needed. This option can be used to streamline the edit process for users. Only one template per type can have this option enabled. Enabling this option on one template clears it from any other that has it specified.
• --removeWordTemplate=value
specifies a Microsoft® Word template to remove from the type. For information on using Microsoft® Word templates, see the Windchill RV&S Help Center.
• --[no]allowDocumentLocks
specifies whether document locking is supported for the specified type.
• --documentLockPolicy=value
specifies which users and/or groups are allowed to lock documents of the specified type. The default value for the policy is userField=assignedUser, that is, only users who are assigned to documents of this type are allowed to lock them. Valid values are userField=<field>, groupField=<field>, anyone, groups=group1,group2,....
• --documentUnlockGroup=group
specifies the lock administration group for the type. Members of the specified group can unlock any locked document of the specified type.
• --[no]allowAdditionalLockFields
specifies whether additional fields (beyond significant fields) can be locked for the specified type. By default, only significant fields are affected by document locking.
• --additionalLockFieldsRule=rule
specifies a rule that determines when additional fields (if allowed) are affected by locking. For the rule syntax, see Specifying Rules on the
options reference page.
• --additionalLockFieldsRuleFile=filename
specifies a file that contains the additional locks field rule set for the specified type. For the rule syntax, see Specifying Rules on the
options reference page.
• --copyAdditionalLockFieldsRule=type
copies the additional field locks rule of an existing type to the new one being created.
• --additionalSegmentLockFields=field,field,...
specifies the fields on a segment root of the specified type that, in addition to the significant fields, are affected by document locking.
• --additionalContentLockFields=field,field,...
specifies the fields on content nodes of the specified type that, in addition to the significant fields, are affected by document locking.
• --[no]lockingRequired
specifies whether a document of the specified type must be locked before the significant fields (plus any defined additional fields) can be edited.
• --lockingRequiredRule=rule
specifies a rule that defines when documents of the specified type must be locked before the appropriate fields can be edited. For the rule syntax, see Specifying Rules on the
options reference page.
• --lockingRequiredRuleFile=rule
specifies a file that contains the rule that defines when locking is required for the specified type. For the rule syntax, see Specifying Rules on the
options reference page.
• --copyLockingRequiredRule=rule
copies the rule that defines when locking is required for an existing type to the new type being created.
• --hiddenMenus=[None|CreateItem|CreateRelatedItem|CreateDocument|InsertContent]
specifies the menus and related dialog boxes where creation or insertion of the item type is to be hidden. When an item type is hidden, it can still be created or inserted from the command line. The options are as follows:
◦ none specifies that the item type is not to be hidden from any menu. This is the default. No other option can be specified along with this option. When item types are to be hidden from menus, multiple options can be specified.
◦ CreateItem specifies that this item type is to be hidden from menus and dialog boxes for creating items.
◦ CreateRelatedItem specifies that this item type is to be hidden from menus and dialog boxes for creating related items.
◦ CreateDocument specifies that this item type is to be hidden from menus and dialog boxes for creating documents.
◦ InsertContent specifies that this item type is to be hidden from menus and dialog boxes for inserting content in documents.
• type
specifies the name of the type you want to create.
• --defaultFieldsForWebUI=field,field,...
specifies the fields that are added to predefined Default Fields in Document Workspace. Only visible fields can be part of the default fields. For more information on Default Fields, see the Windchill RV&S Help Center.
See Also
