The Due Date on Change Orders needs to be more accessible to change for the Change Admin.
Right now the Due Date can only be edited in the Create or Open state of a CO. Often this date is a stab in the dark and really can't be set until the CO is further along.
The Change Admin needs to be able to edit this date at almost every state of a change. Right now the Change Admin must recend the change back to the Open state to change the date and then push it forward again. Alot of wasted effort just to change a date.
In Vault Professional 2013, we could filter Item BOM rows using the column header filter:
In Vault Professional 2015, someone has decided to completely remove this. Why?? This is counter productive and I can't imagine anyone would ask for something useful and harmless to be removed. Please reinstate this functionality ASAP. I know the filter is available for standard system properties, but this is a custom UDP. I'm also aware of the 'Group By' function but this was more convenient and user friendly.
Basically we will use automatic backup scripts to backup Vault periodically, the problem is we don't know if the backup process succeeded or failed, so administrators are forced to log into the server to check the backup log now and then. It will be very helpful if vault can tell me this information, especially when it failed.
Due to the huge impact of the purge operation on SQL and on replication performance in particular, would be useful to receive from the purge command and estimation about the number of files that will be purged and associated records to be replicated prior to the purge run. Also would like to have a more selective purge, for example by folder, in order to split the purge workload through different weeks.
I understand this issue is already with the product dev team, but as it still hasn't happened and made it through to RTM software, I think it should be formally logged here.
I've had to instruct and be quite strict on users in that they're under no circumstances allowed to open any CAD drawing/file/model directly from Vault. So no right clicking on files in Vault and using 'Open'. Why?
Two reasons. The first was that the files opened using Released Bias settings. That was resolved in Vault 2015, but not quite enough to make it usable.
Second reason is that properties are not synchronised during the open, so title blocks & iProperties don't update during the open. It can be manually updated after the open but I have too many users to expect this to always be done.
Please offer the property sync on Open through Vault. This happens when opening via the CAD client, need it when opening from Vault.
The new Item workflows are great but need some improvement as they can be really clunky. The majority of the problems are due to the fact that we can only actively edit one Item in session at a time. For example.
1) Open and edit an Item. 2) Go to BOM tab. 3) Right Click > Add Row > From New Item
This will create a new Item and add it to the BOM at the same time, this is great. However, the new Item doesn't have a title or a description. To enter a title or description, we have to exit edit mode of the parent item, click yes to save, right click the child item, Open the new item, click the edit button, then type in the data for title or description. If we've created 10 new child items, that becomes a real unfriendly and painful workflow.
I'd love a 'right click > Edit Properties' function for child Items in the BOM. This would bring up a dialogue box to enter properties for that Item, title/desc/custom props etc. Something like this:
All Vault properties are subject to rules such as "Requires Value" and "Minimum Length". If a property does not have a Value or meet the minimum length, a property non-compliance is raised and requires user input to rectify. This is really important for when a property must be completed for audit purposes and especially for exporting data into ERP systems.
ECO properties have these rules but they are completely ignored. I need to make sure users enter a value for these ECO properties but the only method in which I have to enforce this is not working, at all. Please fix ASAP.
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.