Hello to all,
I suppose you have configured your Vault Workgroup 2013, so that files can be released only if the dependent child files are released or would be released.
Due to a security, it is now possible to bypass this law and release these files, although the dependent, subordinate child files are NOT released! (child files are still in work process)
Attached the screenshots as PDF approach. I used it the Vault default configuration.
I hope you can understand the work process, because I use a German version of Vault.
Ask for feedback as to whether this behavior occurs the same way in your language version of Vault.
If you have any question e.g. about translation of german words in the screensot's, don't hesitate to contact me!
Thanks
Franz
Additional Information:
This mistake occur whenever you change the category of a file.
Because, in another step the simultaneous change of lifecycle (from A to B) and status (in progress => Released) Vault no longer checks the system whether the subordinate documents are already released !!!
Hi Franz,
Thanks for posting this to the forum. I believe this issue is consistent with your previous support submission related to changing the document category of a files children (without updating the file references) prior to releasing the parent, this time with a small difference.
In this instance the team has identified a specific workflow in which changing the lifecycle scheme of a file after adding to Vault and not updating the file results in it no longer referencing the correct versions of its dependents, allowing you to release the parent independently of its children.
In my testing changing category has no effect on the dependency or transition rules (only lifecycle scheme change) and by updating the file the correct behavior is observed. Development are looking at a resolution to this specific workflow.
I hope this helps,
Hello Allen,
thank's for your feedback.
About this issue there is a support case (ID 08487089) for serveral month, but it is not certain that these errors autodesk repaired 😞 !!!
w. kind regards
Franz
Hello,
the workflow shown is dedicated to a unique role and access control that only the system Administrator should have. The ability to simultaneously switch lifecycle definition and state has to be limited for the end users (engineers, design manager, CAD admin). I did different implementations to achieve this: you need to split the role of "Document Manager 2" (allows to switch lifecycle) and the ability to perform the step of release.
I appreciate if development is looking into this additionally, but first hand it's more on our side to setup lifecycles / transitions accordingly.
Best Regards,
Markus
Hello Markus, thanks for your answer. Your proposed solution is basically possible, but it has one major drawback.
Downgrading rights of engineer-usergroup to 'Document manager 1' prevent lifecycle switch. But 'Document manager 1' can change category and switch status to released. Now so it is possible to change category of file and switch to 'released', but with bad effect of wrong assigned lifecycle!
We prefer separate lifecycle for each category of document to realized individual access control in each lifecycle status. In this initial situation your soulution is not really useful - sorry. In addition, this is a workaround and not a problem solution for the causative fault, but anyway thanks for your help.
With kind regards,
Franz
I agree with Markus on this.
We have had several customer in the past attempt to use the system in this way, and it just becomes a mess.
A category is not meant as something that indicates a phase in the design or another type of status, it just does not work well for this.
If this is what you are attempting to do I would not recommend it. I would recommend either adding more states to your lifecycle definition (you can have as many as you wish).
Or have some additional properties to store this information.
I don't want to imply that the issue you have raised is not a bug. It sounds to me like it is. That being said I can not say when this defect might be resolved.