Vault 2012 Pro Lifecycle Bug

[Anonymous]

I have discovered what in my opinion is a bug with the way multiple lifecycles are handled in Vault.  In our vault we have two lifecycles set up: 'engineering release' for all CAD files and drawings, and 'library release' for all Libray items (gearboxes, bearings, motors etc).  The library release is restricted to the CAD Admin group only, as a way of limiting editability of the heavily reused library items, and ensuring they have 100% correct iproperties and dimensions.

The problem I am experiencing is on adding a new library file to Vault.  When the files get checked in for the first time they are automatically assigned to the engineering lifecycle.  when it comes time to release the files, we have been changing both the lifecycle (engineering >> Library) and the state (WIP >> Released).  The issue is that compliance is not being evaluated and a ton of non-compliant library files have been released because of this.  Additionally, synchronize properties and update view were not triggered on the transition to released - drawigns are out of date and visualization files aren't available.

I've determined that the issue is because the compliance is only evaluated when lifecycle is the same and the sates change.  changing lifecycles and states at the same time means that the state transition rules aren't triggered since there isn't any criteria for the transition "engineering, WIP >> Library, Released".

The workaround is fairly simple, but adds another level of unnecessary steps: Change state>library>ok, change state>released>ok.  It is a pain to run change state twice, but it workable.

My question for autodesk: Stepping back from the details above, why does Vault allow me to release non-compliant files?  To me this is a fairly big hole because it also stopped the synchronize properties and update visualization actions.  At a bare minimum you should be prevented from changing lifecycles and moving to a released state in the same step.  Better yet, on changing lifecycles the file should probably be forced to take the first state in the new lifecycle's workflow.

Can anyone comment on the above, or suggest a better way to protect this from happening again?  My fear is that this lesson will be forgotten one day, and our guys will be in a rush, see that it's possible to change both the lifecycle and the state in one go - and we'll be right back where we started again with junk released files.

Thanks!

John

Vault 2012 Pro x64, Update 1

[luttena]

Hi John,

I know exactly what you're talking about and I'm glad you posted it because it's good topic to review every once in a while. As you pointed out, Vault does not allow the administrator to configure any transition criteria, actions, or security between different lifecycle definitions. While there are several good design reasons to leave this functionality out, the quickest answer is to say that this workflow is not intended to be a typical scenerio. Yes, you will occasionally have a need to change the lifecycle definition of Vault data. But the design focuses around keeping those objects in the same definition throughout it's lifecycle.

Since there is a need to change that lifecycle definition, it is allowed. But it is restricted to only administrators and Document Manager (Level 2) users. My first recommendation would be to limit the amount of users with this permission if possible. Maybe Level 1 would suffice for most?

Regarding your question about blocking the releasing of non-compliant files, we try to limit the amount of 'hard rules' that we enforce on the user and aim for allowing the administrator to make the rules. While I completely understand your need to block this, there are other users that would not want the software to make that choice for them. Since there is no correct answer for all, the answer is to give the administrator as much control as possible. We do have methods for you to prevent the release of non-compliant files and we also restrict lifecycle definition changes to certain roles.

Instead of assigning all CAD files to the engineering category on check in, can you assign the library files to the library category immediately? This would allow you to start in the correct lifecycle definition and end there too.

If you are interested in how to build a category assignment rule for library components, please take a look at this blog post by Brian Schanen: http://underthehood-autodesk.typepad.com/blog/2010/08/categorizing-inventor-content-center-files-wit...

He actually has a nice step-by-step tutorial on how to do this.

Please let me know if this will not work for you.

Regards,

Adam

[Anonymous]

Hi Adam,

Thank you for the thoughtful reply!  After posting I was thinking that categories would probably be the answer.  A little background on our situation:  we've had Vault pro running for about 3 years, but it was never configured properly from the beginning, and recently we made the decision to abandon the entire database and start fresh.  In combination we are reviewing some of our internal processes, how we issue drawings etc and integrating that with vault processes.  We are now seeding the new vault database with a selection of good quality models, and will be going live very soon (1-2wks).

As you can imagine this is a major project, and to date I've avoided categories as they add another layer of administration and configuration.  Brian's solution is a good one for CC, but i'm not sure I can apply a similar rule to library parts.  I don't have an iProperty which defines Library from regular parts.  The distinction is somewhat qualitative and is only made when an admin moves the file from a design folder to a library folder.  I did a bit of quick playing around with the rules and couldn't find a way to create a rule based on folder path.  Can you make any suggestions here?

This is all leading me to in the direction that we will just have to be careful when changing lifecycles and distinguishing certain parts as library.

Thanks,

John

[luttena · Accepted solution]

Hi John,

You're right. I neglected to notice that you're referring to in-house library components. Since components are not determined to be library components until late in the process, the category workflow is not a great option.

Here's another suggestion for you:

Instead of relying on another lifecycle definition, maybe we can simplify the situation. What if you added a new lifecycle state to the Engineering lifecycle definition? The security of this state can be configured so that only the right people have access to them and the ability to edit them. More importantly, you can configure the transition between the states so that only those select few team members can even move it to that transition. You name it something like Released [LIB]], for example.

This solves your issue with running things like actions and property compliance checks on transitions.

Thoughts?

Adam

[Anonymous]

Hi Adam,

This is doing the trick!  It took some time to configure all the transitions for the new lifecycle, but that's done now and the right users and groups can/can't make changes to released library file  - all without the need for a second lifecycle.

I've left categories alone for now - anything ipt/iam/etc becomes Engineering, all else stay as base. 

I have noticed something as I'm going through our libraries and changing the lifecycles on the p[reviously released parts - it seems like you are blocked from changing the lifecycle of a component that's in a released state. (A good thing IMO)  To me it would make sense if the reverse was true too - Vault shouldn't let you take a WIP file and move it to a released state in a new lifecycle.  That may be too restrictive for other user's applications though.

Thanks for all the help!

John