February 2017

02/27/2017

Almost a decade ago Autodesk reintroduced the DWG format to Autodesk Inventor in order to facilitate a greater collaborative effort between AutoCAD and Inventor. New benefits such as adding Inventor views to AutoCAD layouts, creating a format any AutoCAD version 2007 and newer can open, using AutoCAD blocks in Inventor drawings, and opening AutoCAD files in Inventor has opened more available workflows for customers. With these new features a new type of confusion arose as well.

What program created the DWG???

Since the authoring program of the DWG has to be one that edits the native geometry of the DWG, a user has to know the correct program in which to open the file and make the edits. For instance an Inventor DWG that contains modeling data will not be able to be exploded in AutoCAD because Inventor contains the modeling and assembly feature data. Likewise an AutoCAD drawing containing vector geometry should be edited in AutoCAD so that the entities are properly modified or adjusted.

Companies will approach this issue a couple of different ways. One way is to segregate the geometry into different folders called AutoCAD and Inventor and maintain those files in those folders. Other methods are not to use Inventor DWGs at all due to this issue of identification thus eliminating the potential benefits of the DWG extension. The only real ways to discern an AutoCAD DWG file from an Inventor DWG file is to right click on it and see if it shows the Inventor iProperties option through the Windows shell integration or use the Provider field in Autodesk Vault to see the creator of the program.

I know right? There has to be an easier way!

Well, thanks to a new enhancement to a tool I have used for a long time, we can now see what program created the DWG directly in Windows Explorer and our Autodesk open windows. This tool will show all kinds of information about DWGs in Windows Explorer such as which version of AutoCAD the file is saved in and a lot of the DWGPROPs in the file. It will even tell if the file is AutoCAD Mechanical, Electrical, or another vertical of the software. But most important is the new field to the tool called DWG Created By which will show if a file is an Inventor DWG or and AutoCAD DWG!

What is this tool? Well, its the same tool created by the company that created many great tools for Autodesk products including an improved license reporting tool for Network Licensing among other productivity tools. This company is JTB World and you can find this particular set of tools in the Autodesk App Store or from their website directly. This tool comes in three flavors...Free, Trial, and Paid. Free will get you only the DWG version and not what we are primarily concerned about in this discussion, the Trial will get you full feature for 30 days, and the Paid version will get you whole ball of wax for all your DWG information needs.

This is a must for any company with mixed AutoCAD and Inventor DWG files in legacy or production use around the company. If you are looking for a large amount of seats there is even a volume discount for your engineering teams. Go check it out and see the other things it can do as well. Even for a single seat it is really inexpensive to increase your sanity and productivity.

02/16/2017

In my previous article, I described the Vault security at the global level, the user and group accounts with their role assignments. Today, we discuss the security available by assigning a lifecycle to a file. I will also include using items, and compare how items handle this issue.

If you use Vault Workgroup or Vault Professional, the release management module is available to you. Release management consists of applying a lifecycle to a file, which also applies a lifecycle state. A lifecycle is defined as having one or more available states, with one particular state identified as the default state. When a file is assigned a lifecycle, the default state is also assigned to that file. That file is then controlled by the security defined in the lifecycle state.

Stepping back to look at the lifecycle definition, we can use the sample definition of the Flexible Release Process. There are five states defined for this lifecycle, with the Work in Progress state identified as the default. This means that any file assigned this lifecycle will be automatically put into the Work in Progress state. If I need to bulk load a large number of legacy files, for example when setting up a new vault, I may find it useful to temporarily set the default state to Released, if I simply need to get those files in the vault and I do not intend to make additional changes to those files.

Each state in the lifecycle has a number of settings associated with it. Focusing on the security aspect, each state has security settings (shown on the Security tab). This listing is called an Access Control List (ACL).

If the box is checked for ‘No state-based security’, then anyone with the global role of document editor (either level) can check this document out and make changes. In the above example, we limit the access. The ‘Everyone’ group is allowed to read the files, but cannot modify, even if they have the document editor role assigned. There are two groups that are allowed to modify and delete files, the Engineering and Administrators groups. If we compare this with the Released state, we see that the Released state denies Everyone the ability to modify or delete files.

One point to make here is the concept of implied versus explicit denial. In the Released state, we see that everyone has an explicit denial of modify and delete rights. If I were to add another group or user to this ACL and set modify to Allow, they would not be able to modify these files because the Everyone group is explicitly denied the ability to modify. Comparing this to the Work in Progress state above, the Everyone group is explicitly allowed to read the files, but there is an implicit denial to modify or delete these files, unless that user is also in one of the other groups that are explicitly given the modify privilege. All users are in the Everyone group, but only those users in the Engineering and Administrators group can modify, in the Work in Progress state. Generally speaking, when I set up a system, the Work in Progress and Quick-Change states allow some groups to edit and delete files. The For Review, Released, and Obsolete states are locked for everyone, since we typically want to keep the files in those states from being modified.

The other security included with the lifecycles controls the transitions, and specifies who is allowed to change from one state to another. Within the lifecycle definition, there is a definition the selected state to and from every other state.

If we edit the state transitions, we again see a security tab with an Access Control List (ACL) that allows us to define who is allowed to or denied from making that transition. In the example below, the Administrators and Engineering groups are allowed to change the state of a file from Work in Progress to For Review. Anyone not in either of those two groups will not be allowed to make that transition. Again, there is a check box to set ‘No restrictions on this transition’, which would allow anyone (with either of the global Document Manager roles) to make that state change.

In comparison, below we see that Everyone is denied the ability to change the state of a file from Work in Progress to Quick-Change. This is not an acceptable state change, so we effectively disable it for everyone.

When we consider using items, we shift all of the lifecycle control to the item record, and we set the items to control the files, based on the item states. In the example below, we have an Item Release Process lifecycle definition. We have a similar set of states, and can configure the state security as well as the transition security in the same way we configured the lifecycles for files. Note that in the item security, we have the option to set the security of files associated with the items, so that the item security is applied to the associated files. A locked item locks the files linked to it.

These lifecycle definitions can be applied to either the files directly or the items, but I strongly recommend not applying them at both levels, with one exception. If we set lifecycle security on an item, and we have an associated file, AND we set a lifecycle for the file, we have a loophole in our security. If I have the item state set to Released and the file state set to Released, the item and file are locked. If I leave the item as Released and change the state of the file to Work in Progress, the file is unlocked, even though the item is locked. The reverse is also true, that if I set the item to Work in Progress and the file to Released, the file will be unlocked and editable. If items are used by your company, you should apply lifecycles to the items and not to the associated files.

The exception I spoke of earlier is for the case where we have a file in the vault that will never be assigned an item. One example may be our Inventor project file. We would not itemize our project file, but we still want to control the users’ access to it, so that it is not modified unnecessarily. In this case, we should apply a file-based lifecycle to this file, so that we can limit when it is modified and by whom.

Through the lifecycle security, we control the file access and when those files can be modified or deleted. If we bring the global security back into the picture, a user with only the Document Consumer role cannot edit a file regardless of its the state. Editors can edit files as long as they are in a state that gives them permission to do so, and administrators cannot edit files in a locked state even though they globally have all permissions available at the global level.

02/15/2017

Last week I shared some tips and tricks as part of IMAGINiT's online Vault User Group. One trick that I wanted to pass on has to do with exporting a user list from Vault. How to export this list is a question I get fairly often, an until recently my answer was, "Well, you can't do that." But then I was working with Dave Unger of The Lubrizol Corporation, and he came up with a better answer.

Below is the user list from one of my sample Vaults.

As you can see, there is no export option. Dave's trick was to select all of the users, and use CTRL+C. This copied the entire list.

Then, he opened an Excel Spreadsheet and pasted the list in. The result is shown below.

And yes, you do have to use the CTRL+C in Vault. Righ-click does not show copy as an option.

Thanks to Dave Unger for this tip. See you (virtually) at the next Vault User Group!