Community
Vault Forum
Welcome to Autodesk’s Vault Forums. Share your knowledge, ask questions, and explore popular Vault topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Serious vulnerability in the release process of Vault!

7 REPLIES 7
Reply
Message 1 of 8
kefer_kb
507 Views, 7 Replies

Serious vulnerability in the release process of Vault!

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

www.gfm.at
7 REPLIES 7
Message 2 of 8
kefer_kb
in reply to: kefer_kb

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 !!!

 

 

www.gfm.at
Message 3 of 8
olearya
in reply to: kefer_kb

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,



Allan
Product Manager
Autodesk, Inc.
Message 4 of 8
kefer_kb
in reply to: olearya

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

www.gfm.at
Message 5 of 8
Markus.Koechl
in reply to: kefer_kb

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



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
Message 6 of 8
kefer_kb
in reply to: kefer_kb

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

www.gfm.at
Message 7 of 8
Markus.Koechl
in reply to: kefer_kb

Hi Franz,
You are right, the switch to another category does not switch the lifecycle once the file already has an assigned one.
And - if your engineering group is allowed to release within any lifecycle you might end up in a combination of category/lifecycle you do not allow by design.
On other hand if your intent is to implement individual access control in different stages of your design process you probably should extend your lifecycle and not use categories to different phases of design. Well this is just guessing based on the hints and restrictions you argue with, not based on a real knowledge of your intent.

Thanks,
Markus


Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
Message 8 of 8

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. 



Mikel Martin
User Experience Architect
Autodesk, Inc.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report