I have a unique request that I think would benefit many users. I have a need to specify a criteria be met prior to a state change. In my example, I need to have a particular property with a value before we can send a file to the next state. This property is not mandatory until we reach this state, so the compliance flag is not displayed for this.
The problem we experience occurs when someone forgets to fill in the required value and then tries to submit the file to the next state. The resulting error message indicates that there is missing information, but is not specific as to the missing or unfulfilled criteria. It would be very beneficial to have the error dialog indicate the particular criteria that failed. If the user could see the property missing the value or something similar to direct them, it would be very useful.
From what I can tell right now, users have very limited control over the visibility of file records in the Thin Client. You can either see all versions of a document or all Released versions of a document. Both options can lead to confusion based on workflow.
What if you want to only show the latest Released version of a file record? You can't do that - all Released versions are currently displayed. Worse, what if you use a lifecycle like the built-in Flexible Release Process and perform a Quick Change? Now you have two versions at a particular revision. The result can be something like this:
To provide better control over file record visibility in the Thin Client, I'd like to see the options for File visibility expanded to a total of four (from the two we have now). These four options would be as follows:
Show all file versions
Show all Released file versions (allow multiple versions at the same Revision)
Show all Released file versions (show only the latest version of each Revision)
Show only the latest Released file version
I think one and four are self explanatory. Two and three might be confusing to the user, but I think they're ultimately necessary. Option two would function like the current 'show only released' versions, and would lead to a list like the screen capture above. Option three would be new functionality, and would hide all Released versions of a particular Revision level except for the latest. This option would hide versions that had been superseded by activities like Quick Change, and so in the example screen capture above, version 6 of the file would not be visible in the Thin Client.
If a user accidently makes a change state of a model from Released to Work In Progress, it will increment the revision, and then leave us with no way to go back to the previous revision. I understand why you would do this, as we shouldn't be going backwards with Revisions, so I don't believe every user should have access to this functionality, but an Administrator should be able to override the Revision if they determined there was a mistake made and we need to go backwards.
I've known this issue has existed from about day one in Productstream and now Vault Pro, but it's time that this security issue is fixed. I feel its a major defect, but they tell me it's "AS DESIGNED".
If you are using items, this has the potential to be costly to your organization. It allows users to print an older version of a file which has been revised and it still shows the water mark of "RELEASED". All without any kind of warning.
We are dealing with items and when an item has several revisions and you toggle back thru the revisions, the drawings linked to that revision still have a water mark of released, even though the drawing is an old - revised drawing.
The attached video illustrates this disaster waiting to happen.
There has to be a way to prevent the printing of older drawings with "RELEASED" on them. The water mark should say "VOIDED Drawing" or the like when a user toggles the revision level back. Any guidance here on how to fix this issue?
I think it is crazy that everytime the state is changed within vault, specifically from "Released" to WIP, I have to synchronize the properties. Why aren't the properties automatically syncing when the state is changed. They should be. Changing states should not be a two step process.
Folder and lifecycle state security is a useful feature, but it can be really hard to use. For example, it's hard to find out which users have access to which folders. Likewise if a user doesn't have access, it can be hard to figure out why. If you are managing many folders, you are forced to manage them one at a time.
One possible improvement to provide a view like in the Effective Folder Permissions app, which unrolls the security settings to show a per-user view.
Vault Feature Request: When you obsolete an item it should obsolete all previous revisions, released or not.
Obsolete Items are still viewable in Web Client because some previous revisions are released
Ref: previous Autodesk case 09411810 and new Autodesk case 09515277
Also see attached Word doc with relevant context as "Obsolete Item scenario - public.doc"
The customer has the advised workflow and has asked for this feature request case be opened with Autodesk to obsolete all previous revisions, released or not.
The reasoning is so that Web Client users cannot access parts in error that are no longer in production.
The business case for this company involves 35 seats of Vault Pro 2014 and several dozen more Vault Web Client users at multiple sites routinely relying upon the accuracy of parts that are accessible as 'in production'.
They do not want obsolete parts being requisitioned or ordered as parts of extensive bills of material, for example.
They understand that this feature request will likely not be made available in Vault 2014. They have the workflow workaround in place as an alternative as detailed in the attached Obsolete Item scenario - public.doc