Change State Error

[Anonymous]

Hello,

We recently migrated from PDSU2015/Vault 2015 to their 2017 counterparts. In 2015, we had a large number of files assigned to the <None> lifecycle definition, mostly skeletons and multibody parts. As a result, Vault ignored these files during the release process. However, that behavior has been altered in 2017, as we now receive the wonderful "Revision A of **** is not released" error for all of these files when referenced.

Can 2017 be adjusted to respect the <None> definition, so that we do not have to modify the states of a huge number of files?

Also, we currently require that all children be released, so that is not an option.

Thanks... I hope...

[achintam]

Hello,

This is based on the lifecycle transition action "Check that dependent child files are Released" that is configured by the admin. If this setting is turned on Vault requires that all children are Released (regardless of their lifecycle definition) before releasing a parent. Maybe this setting was turned off in 2015 and turned on in 2017 for you?

Hope that helps.

Regards

Anil Chintamaneni (Autodesk)

[mark.cloyed]

Hello,

I just tested this in both my 2015 and 2017 environments, using Vault Professional.  In both cases, I have a file with a child link to another file (Xref/Inventor parent child).  The child is in the base category and as such does not have a lifecycle or state associated to it.  The parent has been put into the flexible lifecycle, into the Work in Progress state.  The lifecycle is configured so that it requires child files to be released for the transition from WIP to Released.  In both environments, if I try to change state of the parent to released, I get the error that the transition cannot be performed because the child is not released, so 2017 works the same way 2015 does.  One would ask at this point, why the child is not required to be controlled by a lifecycle.  If the parent depends on the child, shouldn't the child be controlled as well?  If the parent is released and the child is editable, wouldn't that provide risk that could invalidate the parent if the child were edited without the parent?

Thanks,
Mark

[Anonymous · Accepted solution]

---

@mark.cloyed wrote:

Hello,

I just tested this in both my 2015 and 2017 environments, using Vault Professional.  In both cases, I have a file with a child link to another file (Xref/Inventor parent child).  The child is in the base category and as such does not have a lifecycle or state associated to it.  The parent has been put into the flexible lifecycle, into the Work in Progress state.  The lifecycle is configured so that it requires child files to be released for the transition from WIP to Released.  In both environments, if I try to change state of the parent to released, I get the error that the transition cannot be performed because the child is not released, so 2017 works the same way 2015 does.  One would ask at this point, why the child is not required to be controlled by a lifecycle.  If the parent depends on the child, shouldn't the child be controlled as well?  If the parent is released and the child is editable, wouldn't that provide risk that could invalidate the parent if the child were edited without the parent?

Thanks,
Mark

---

That setting has been enabled since this particular vault was setup.

For some of the companies I support, the assemblies and children are isolated, and do not interact. So, yes, you would not want the children to be edited. In other companies, most of the assemblies interact and are fed by numerous skeleton & multi-body parts which feed critical data to multiple parents.. Even though one assembly may be released, the skeletons also affects other non-released files. This has not created any issues since the released files are locked until a state change is initiated. Although I cannot explain why setting the lifecycle definition of the skeletons, etc. to <None> allowed the parents to be released (in 2015), it has been an extremely effective workflow, allowing me to release those parts/assemblies as needed.

However, this does not function now, so the point is moot, and either the "...children are released..." setting must be disabled or a lifecycle defined.

Thanks for the responses.

[Gabriel_Watson]

In our company we have a special lifecycle state that is used before Released, and we would like to have Vault verify, when transitioning to this previous state, if all children files are also moving up or at that same pre-Released state.

Is there any customization in Vault which allows us to verify this yet?

[mark.cloyed]

Unfortunately, there is not a way that I know of to validate that the children are all up to that "Approved for Release" state, unless you define the "Approved for Release" as a 'Released' state in the lifecycle definition.  Then, the validation test should work and require that the children are either Approved for Release or Released.  Otherwise, all you can do is train the users to look at the parent file's 'Uses' tab to verify that the children are in that state.

Thanks,
Mark