Different revision sequence for different contexts

[DonSenchuk]

A hypothetical has been lobbed my way and I don't have a concrete answer.

We have 20 Contexts and Libraries. They all use a simple revision series; -, A, B, C, etc.

The new question I've been asked to explore is whether it's possible to have one (or perhaps more than one) context/library follow a different revision series; -, -1, -2, -3, A, A1, A2, A3, B B1, B2, B3, etc.

I feel like I saw something about this being possible some time ago, but I've yet to get any sort of useful results on the eSupport Portal for any query since PTC "upgraded" it awhile back.

So, is it possible to have different revision series for different contexts/libraries? If so, where is this outlined?

[TomU]

Don,

I'm just starting to get into this myself, but from what I understand the object initialization rules (OIRs) determine the series used. I believe these can be defined at the org level and then also at each product/library level. I have one specific product that I'm going to switch over to state based versioning and it will use a completely different versioning series than everything else. If you can't find any good documentation, Mike Lockwood is a great resource.‌

[LoriSood]

Don,

Tom has the right idea. You can create context-level (product/library/project) OIRs and have a different versioning scheme referenced than is referenced at the org or site level. The OIR evaluation hierarchy is product/library/project, then organization, then site. What this means is that attributes defined at the product/library/project-level take precedence over what is specified at the org and then site level. The org and site level OIRs are evaluated only for attributes that are not set in the already evaluated OIR(s).

The product/library/project-level OIR would need to only contain the following in order to just change the versioning scheme (in this case for a WTPart, changing the versioning scheme to a custom file-based scheme called MYSERIES):

<AttributeValues objType="wt.part.WTPart">

<!-- set the version info to a generated version info -->

<AttrValue id="MBA|versionInfo" algorithm="com.ptc.core.foundation.vc.server.impl.VersionInfoGenerator">

<Arg>wt.series.HarvardSeries.MYSERIES</Arg>

</AttrValue>

</AttributeValues>

[Dobrisa]

I know it's a few years old but still curious:

When you want to apply different OIRs to different contexts, is it as simple as just uploaded that OIR XML to the context Utilities/OIR page? I've tried this and somehow the context column still shows "Site" whereas I would have expected it to show the context for that specific OIR. 

[mmeadows-3]

Depends on how you 'upload' the OIRs.

Only site OIRs exist OOTB.  If you have Site admin permissions and you Edit an OOTB OIR from the Organization level, you are still editing it at the Site level OIRs.

Navigate to a lower level context > Utilities > OIRs Administration.  Define a 'New' OIR at this level.  Specify the name, desired type, and load your OIRs file.  An OIR defining the same type (e.g. wt.doc.WTDocument) may persist at each context level.  However, we can't create two OIRs defining the same type in the same context.

[BenLoosli]

I have an org level OIR and the context column shows the org name.

I just created a test OIR at the Doc Lib level and it shows Document Library in the context column.

Do you have admin rights to the context? Only an admin, I believe, can add or edit an OIR, lifecycle, workflow, etc.

[Dobrisa]

I have Site admin rights so it's not a permissions issue. 

What I was trying to do is edit an existing OIR (which OOTB was at the Site level) and hope that it would apply only at the context level. 

I did just try creating a new OIR at a Product context level and it does in fact apply only there. 

Thanks!

Dobi

[DonSenchuk]

So it's definitely possible, which is good news.

Follow-up questions;

How does this affect moving files from a context with the normal series to the context with the special series?

Because the movement should always be from the normal context to the special context, and all the revision letters found in the normal series will be found in the special series, will everything work without hassle?

In the rare event that a file has to be moved from the special series to the normal series, what happens then? This is especially important if the EPMDoc has revision E3 in the special series but that revision isn't part of the standard series.

[LoriSood]

The versioning series for objects does not automatically change when you move them to other locations. There are utilities that can be used to change that, such as MasteredSeriesCleanser.

See https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115808 for more information.

This is an article on how to execute it from a windchill shell in the later releases (10.1 and later): https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS135640

You will need to make sure that the objects that are updated are set to a revision level that exists in the new versioning schema as there can be problems when creating new revisions after the versioning scheme has changed. See https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS30667.

[TomU]

Lori,

These seem to more deal with a global, system-wide change. Changes made to the source series. These require a complete stop and restart of Windchill. I don't think that's what we're looking for here.

If two contexts have separate OIR's specifying different series, how to you change the series on just one object when moving it from one context to another (without altering the database or restarting Windchill)?

[BenLoosli]

I have always been under the impression that you cannot move files between contexts if the contexts have different revision schemes. Lori says you can IF the file being moved is at a revision that is valid for the target context.

A file at revision E3 could not be moved into a context with a standard revision sequence of ...D,E,F,G... until that file was revised to rev F.

[Dan_Harlan]

I do believe you can move between contexts if the target has the existing Rev in its series. Note that you can "hide" values in a sequence so they are only available for legacy or moved types of objects. But I don't recall the details on how to do this.

Do be careful and test, for instance if your "normal" series is A, B, C and your target series is A, A1, A2..., B, B1, B3 then make sure that when you move a Rev C object stays at C and doesn't become A2 (i.e. the third value in the target series). (I don't think this happens, I think I remember this from ProI 3.4, but, better safe.)

Consider Keir's comment carefully, make sure that this "special" rev series isn't just a work around for a weak policy somewhere else. i.e. such as if this is a consideration for dealing with unincorporated ECO's or prototype releases.

[kpritchard]

I may be having fuzzy recall here, but moving and changing Versioning Scheme may be limited to provision for existing (current and previous) Revisions being available in the new versioning scheme... but maybe it is just the current Revision. Personally, this alone would have me pushing back a bit and trying to understand what is needed (Why?), and looking at other ways of satisfying the root requirement. Maybe what someone is after would be better achieved by Lifecycle States?