Skip to main content
D
DonSenchuk12-Amethyst
12-Amethyst
April 17, 2015
Question

Different revision sequence for different contexts

  • April 17, 2015
  • 4 replies
  • 5270 views

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?

4 replies

T
TomU23-Emerald IV
23-Emerald IV
April 17, 2015

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.‌

L
LoriSood23-Emerald I
23-Emerald I
April 17, 2015

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>

D
Dobrisa1-Visitor
1-Visitor
September 12, 2019

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. 

M
mmeadows-316-Pearl
16-Pearl
September 12, 2019

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.

D
DonSenchuk12-AmethystAuthor
12-Amethyst
April 20, 2015

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.

L
LoriSood23-Emerald I
23-Emerald I
April 20, 2015

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.

    T
    TomU23-Emerald IV
    23-Emerald IV
    April 20, 2015

    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)?

    K
    kpritchard1-Visitor
    1-Visitor
    April 21, 2015

    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?

    Terms & ConditionsAccessibility statement