cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Organization Level OIRs

ChiselnMallet1
12-Amethyst

Organization Level OIRs

I am trying to work backward from creating a new workflow for promotion requests... I want to make an additional lifecycle to select from.  I need to edit the OIR to allow a drop down for lifecycle selection. But... I just noticed that at the organization level.. I have both the site-OOTB and the slightly modified organization level OIR in the list.  My question is... how does windchill pick which OIR to use?

 

Thanks for any insight!

1 ACCEPTED SOLUTION

Accepted Solutions

Yes - very important.

The system first looks to OIR in the product/library. If not found, looks at Org level. If not found, looks at Site.

One can have complete OIRs at each level or only for example specify the lifecycle at a lower level.

 

Have to use the composite in order to combine them to verify in the OIR table.

View solution in original post

17 REPLIES 17
Florent
14-Alexandrite
(To:ChiselnMallet1)

The system compiles all applicables OIRs from the Site to the context level and generates a "composite rule".

You should read the help center section: Understanding Object Initialization Rules (and sub-pages).

 

Florent ROUSSEL
www.4cad.ca
mmeadows-3
13-Aquamarine
(To:Florent)

Best practice is to not touch the Site OIRs.  Site OIRs are a complete set defined by PTC.  Customers can override one or all of the Site level OIRs by defining customer specific OIRs at the Org (or lower levels as appropriate).

w/Matt - best practice.

Good to carefully document for any admin's involved to leave all at Site level alone and override at Org level.

 

An additional option is to create a Product or Library and have only the Manager Role in it, in order to test this sort of thing isolated from what users see (if you don't have a rehosted test environment).  In that test area, create Lifecycle, workflow template, Promotion mapping Preference, OIR, any needed ACL's in order to fully test.  Once proven, can export all, import at Org level.  Have to re-map preference which calls the workflow at Org level. Easy to get mixed up - helpful to have a block diagram.

And thanks for the tip... we don't have  rehosted test environment as of yet!

That is to say then... the lower level OIR will be chosen over the parent level OIR?

Yes - very important.

The system first looks to OIR in the product/library. If not found, looks at Org level. If not found, looks at Site.

One can have complete OIRs at each level or only for example specify the lifecycle at a lower level.

 

Have to use the composite in order to combine them to verify in the OIR table.

Gotcha...  Making more sense now...  Also I don't see an ACL for promotion requests anywhere?  I had to make one for peer reviews... why is there no ACL?

Promotion Request ACLs are defined OOTB at the Product and Library level.  Companies regularly move all Product/Library ACLs to the Organization /Default/PDM domain to simplify and reduce their ACL caches and configuration burden, but it is extremely rare for a company to modify these ACLs.

 

What is the requirement for modifying the Promotion Request ACLs?

 

I don't have a need to change it at all... just still trying to understand where everything lives!  As soon as I think I understand something... i run into something unexpected!  I was expecting to see promotion request ACL's along side everything else... but nope!

Thanks for the explaination... I now see the ACLs at the product levels.  We're not  a big company... we could likely get away with these at the PDM domain i 'spose...

 

but I'm a nube and if it ain't broke...

ACLs are to the object type PROMOTIONNOTICE.

Note: Makes sense to have Read and Create, and possibly (not likely) Delete. Download doesn't make sense. Modify makes sense if you enable being able to Rework promotions.

Note: Tying the workflow to the promotion is done thru the lifecycle template normally but not for promotion. It uses a special preference.

I really was only going to add the new promo life cycle so that i could test it with out touching the original.  But if I use your test product method... I can just create these things at that test product level keeping it separate from all the other users. 

 

Once I get it to work I can move it over.

I appreciate all the info so far... I'm making head way... I can't seem to wrap my head around how I associate my new lifecycle with my new workflow.  Going to take a crack at altering the workflow though.

 

My new lifecycle added a phase to the promotion request  |open|under review|UNDER APPROVAL|approval|reject

 

I am modified workflow works exactly like like the original... except that under approval acts just like the original approval phase, but with out setting the state of the promotion objects just yet.  I want a notification to go out that the drawings are under approval.  But in addition, a task and notification goes out to our Change Admin to give final approval.

 

I've attached a screen shot of my lifecycle and workflow.

In general one selects a workflow template from within the lifecycle admin UI, from a specific state.

 

Promotion works differently. The method to select a workflow is from Utilities, Promotion Preference Management.

It's a bit involved. Have to create a "placeholder" for the target state at Site, then override this at Org or Product/Library.

Trust me - it will be a bit of a thrill when you first get it to work 🙂

It's because one can set up different workflows depending on the state promoted to that this exists - and it actually works very well. Can even have different workflows to the same state in different products as needed.

Thanks!

 

I have been able to perform a promotion request with one glitch... my promotion request seemed for follow my new lifecycle... the promotion request made it to and thru my added phase... but... my promotion targets were set to release before the end of the promotion request.  So they were triggered likely with at the original activity.

Ok... found the issue and it worked!  I didn't realize what some of the conditional connectors were doing... I just needed to move them down the bus after my new portion of the work flow...

 

What would happen if I added promotion state changes in the Workflow that didn't exist in the lifecycle?

Sorta Worked!

 

In my work flow if the activity shown as Final ECO Approval goes to rework... it gets hung up at the AND connector right before the Final ECO Approval activity.  It won't initiate Final ECO Approval activity the second time around.

 

Any ideas?

Top Tags