Change the colours of the 2 locked file icons in Vault Workgroup and above. Currently they are grey and beige. On a monitor with high resolution it is very difficult to see the difference between them. See the below picture. Locked and local up to date is fine. BUt maybe locked and not up to date could be yellow or red or some constrasting colour.
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.
When creating and working with lifecycle states, I want to be an environment like this...
Something with boxes and arrows that I can drag around. I graphical approach like this is easier to work with and provide an easy way to see how files get routed through the entire lifecycle.
There are a lot of automatic processes that run on the Vault server that are critical to daily usage. If any of these processes fail, administrators need to be notified so that the issue can be addressed ASAP before the system gets into a critical state.
If the processes go unmonitored or errors are not addressed in a timely manner, the Vault system can get into a critical state making it impossible to use until the issues are addressed. It can also affect users daily work as they may not be able to get files needed to complete their work.
Create an alert feature in Vault that notifies specific users/administrator of potential problems with the Vault processes. This should be in the form of an email with possibly attaching log files and other important information in the alert.
Samples of things that need to be monitored:
- File replication
- SQL replication
- ADMS Console backup
- Database and file store size
I hope that in the future versions of Vault Professional, I can use of the Inventor Revision Table linked with Revision of Items. This option would give a high value to Inventor Revision Table.
When I click on a file in the File list it should open the dwf on that click, needing another clikc to open the file is cumbersome. All of the history, uses etc, could be shown on a browser frame to the side or at the bottom. This should at least be an option.
Along the same lines as auto numbering (or Auto naming) should be included with copy design, there should also be the control of file category management.
There should be the ability to manage the current category, to be moved/changed to another category.
ie. R&D files copied to be used for production.
Usually there are more than one category / lifecyle that files will have to be managed with.
When it is being sold as the integration point for Vault, the Item Master is inadequate.
First, lifecycles for items should be as configurable as for files. If you use the system as intended and control the lifecycle of the file through the item, you are severely constricted.
Items should assume the properties of the files that created them, or they should be easily called through the API.
Given the possibility that an item could be created before the CAD representation exists, there needs to be an ability to attach a CAD file as a representation of an item after the item has been created (this is also a huge hurdle if a company converts a product from 2D to 3D).
Document item types should exist so that external applications can reference and control files that don't represent parts.
OR do away with the item master and integrate the BOM capabilities (for 2D and 3D) of item master into the file interface and do away with item master altogether.
This would probably help with any plm integration, PLM360 included.
We need to be able to rename iparts and iassemblies after they are created. Currently when I try to do this, I get the message like "Operation failed.! XYZ.ipt is a configuration memeber whose name is define by keys within a configuration factory".
We also need the ability to easily fix the iassemblies after the iparts are renamed. Right now it is a nightmare to rebuild the iassemblies after the iparts are rebuilt.