si setpolicysection

CLI Reference > Server Administration Commands > si setpolicysection

si setpolicysection

sets policy settings for a new or existing policy section (global or project)

Synopsis

Description

si setpolicysection sets policy settings for a new or existing policy section (global or project).

A policy is a collection of configuration management statements. Windchill RV&S uses policies to establish a shared working environment and to provide cross-platform compatibility. Windchill RV&S references these policies whenever a user invokes a configuration management operation. Because policies establish sitewide and project-wide standards for Windchill RV&S, they should be maintained by the site administrator.

You can set policies at the global and project levels. By modifying policy options on the Windchill RV&S Server, you can configure configuration management functionality across an entire site. Global policies apply for all projects hosted on the Windchill RV&S Server. Project policies apply to individual target projects and establish the way Windchill RV&S operates when dealing with those projects.

• The ViewPolicy and EditPolicy permissions are required.

• By using si setpolicysection and the other policy commands with scripts, you can automate the setup of configuration management policies. To manage your configuration management policies, PTC recommends using the Windchill RV&S Administration Client.

Policy Syntax

Each policy uses the following syntax:

policyname=value

and you can set attributes in the following syntax:

policyname;attribute=value

A semi-colon is used in formatting attributes.

Currently, there is only one policy attribute available: locked. The locked attribute stops a more precise policy from overriding the locked policy and also stops a client from manually overriding that policy.

For example, at some sites it is desirable to set configuration management rules that apply to everyone on the system. This might be the case in a multi-user, networked environment, where you may decide that a strict-locking policy should be in effect for all users.

Contents of a Policy

A policy has multiple sections. The first section is the set of global or default policies that apply server-wide.

Any created project policies use the format /path/project file name.pj, for example, /src/teama/project.pj. These are project-specific policy overrides where each project policy affects all nested subprojects of that project unless the project policy itself is specifically overridden by a lower-level subproject.

The following example sets a global policy to ignore missing archive descriptions except for the sample project /src/teama/project.pj, where ArchiveDescriptionRequired is set and cannot be changed:

ArchiveDescriptionRequired=false

[/src/teama/project.pj]
ArchiveDescriptionRequired=true
ArchiveDescriptionRequired;locked=true

When working with shared subprojects, Windchill RV&S uses the actual name of the subproject in the repository rather than its relative name in the project hierarchy.

Setting Policies for a Development Path

You can also manually create a section that allows for policy overrides within the context of a development path or variant project. This type of policy override uses the format /<path>/<project file name>.pj;<development path name>, for example, [/src/teama/project.pj;Release_1a]. Development path policy overrides can be entered at the global level or at the level of a project or subproject.

Global policy sections for development paths are only consulted if the configuration path of the object being queried corresponds to a top level variant project. For example, if you have a configuration where a subproject is on devpath2 and the top level project is on the mainline (or another development path), then the policy section [;devpath2] is not consulted when establishing the policies for the subproject, even though the subproject is on devpath2.

The following shows the syntax that sets a global policy to enable the workflow and document integration for all variant projects and subprojects under the Release_1a development path:

[;Release_1a]
IntegrityManagerEnabled=true

In this example, change packages are explicitly disabled for the build project under the Release_1a development path:

[/src/build/project.pj;Release_1a]
ChangePackagesEnabled=false

Syntax for Policy Options

This section describes the syntax for available policy options.

For detailed descriptions of policies and policy options, see "Server Policies for SCM" in the Windchill RV&S Help Center.

General Policies:

• RevisionDescriptionRequired=true|false

• ArchiveDescriptionRequired=true|false

• StoreTextByReference=true|false

• DeferredOperationsMandatory=true|false

• RestrictNewRevDeltaToVariant=true|false

• CheckMemberPermissions=true|false

• MemberAlwaysWriteable=true|false

• SymbolicLinksEnabled=true|false

• RevisionChecksumsEnabled=true|false

• StoreSBRRevisionsToVault=true|false

• DisableVisualDiffAndMergeForStoreByReferenceMembers=true|false

• TextWorkingFileSizeGovernor=0

• IncludeFilter=file:pattern

• ExcludeFilter=file:pattern

• BinaryArchivePatterns=.file_pattern

Change Package Policies:

• ChangePackagesEnabled=true|false

• UseChangePackageTrackingLabels=true|false

• ChangePackagesMandatory=true|false

• ChangePackagesTransactional=true|false

• ChangePackageReviewEnabled=true|false

• IntegrityManagerEnabled=true|false

• IntegrityManagerIssueMandatory=true|false

• ChangePackageReviewRule=UserGroupList

• ChangePackageWatcherRule=UserGroupList

• ChangePackageDescriptionTemplateEnabled=true|false

• ChangePackageDescriptionTemplate=template_text

• si.cp.issues.fields=ListofFields

Lock Policies:

• TextArchiveLockingPolicy=nonexclusive|exclusive|none

• BinaryArchiveLockingPolicy=nonexclusive|exclusive|none

States Policy

States=SpaceDelimitedList

Keywords Policy

Keywords=ListofKeywords

IgnoreKeywords=true|false

Line Terminator Policies:

• PreserveLineTerminatorsInTextArchives=true|false

• si.lineterminators=crlf|lf|native

Windchill RV&S Client Default Policies:

Server-side command and view policies set client-side command and view preferences. See the si setprefs command for details.

Additional Policies:

Additional policies are policies that are not rendered graphically, certain custom or workflow and document (IM) policies for maintaining backwards compatibility, for setting client-side triggers, or permission inheritance policies for development path ACLs.

other=other

Options

This command takes the universal options available to all si commands, as well as some general options. See the options reference page for descriptions.

• --[no|confirm]createPolicySection

specifies whether or not to create a new policy section, if the specified policy section does not exist.

• --policy==policy key[;attribute]=value

specifies the policy setting name (policy key), policy attribute (if applicable), and policy setting option (value) for the policy section. To set multiple policies, specify this option for each policy.

Policy keys are case-sensitive.

• --resetPolicy=value

specifies to reset the specified policy option in the specified policy section to the default. This deletes the specified policy from the specified policy section (as well as the lock or append attributes from the policy, if set).

• This option is mutually exclusive with the --policy option. This means that you cannot set one policy and reset another policy in the same command.

• To reset multiple policies, use this option for each policy.

• Resetting each policy in a policy section is equivalent to deleting the policy section.

For example, to reset the value of the IntegrityManagerEnabled policy and unlock it in the global policy section, type:

si setpolicysection --resetPolicy=Windchill RV&S ManagerEnabled :global

• policy section name...

specifies the policy section to set, where policy section name is of the form project,devpath. For example:

◦ :global for a global policy.

◦ <project> for a project, for example, /demo/project.pj.

◦ <project,development path> for a development path on a project, for example, /demo/project.pj;Variant1.

◦ development path for all projects that are configured on the development path at the top level, for example, ;Variant1.

You may need to escape the ; in your command line environment, for example, enclose it in "" or escape the individual character with a /.

Diagnostics

See the diagnostics reference page for possible exit status values.

Preferences

Using si setprefs or si viewprefs, you are able to set or view the preference keys for this command.