Unlock The File Using A Third Party Tool. Sometimes, the file remains locked, even though it shouldn’t be. You could manually unlock the file by closing Windows.

The Change State command always has to be available for both locked and unlocked files. Otherwise you could lock a file by putting it in released state and never get it out of that released state. After some planning, the security can be configured appropriately so that only the right people can make those modifications to the file.

For example, you can configure the lifecycle definition to only allow certain people the right to make certain state changes or to have access to files in certain states. I suggest looking at the transition security on your system. The system is very configurable and can be a very powerful tool.

As for document and item lifecycles being used together, it certainly can be done, but many users choose to drive the security through one system. For example, you can drive lifecycle states and security through the document lifecycles but still use Items for BOM data, ERP integrations, etc. Regards, Adam. Locking files by transitioning to a 'Locked' state works great! I've assigned the Administrator group as the only ones allowed to transition in and out. I'm considering creating another stated call 'Locked and Released' as an extra tool for administrators who want to lock a released file but keep it in a released state so other parent files can be released.

(the locked state would be a 'released state') This will be necessary if you mandate that children be released before their parents. I haven't tried it yet, but it seems like it should work.

Honestly though, it's nice to have these tools available to the administrator, but right now I can see a time we would use them. The whole driving factor for all of this was so I could do one thing.lock the project file. I hope someone finds this useful. They have taken that functionality away! Rihanna Fading Download Free Mp3 here. You can set the item linked to the file back to WIP which will unlock the file or if you have admin rights you can change the file properties to allow a specified person group to open the file, The 'locking' is actually denying you write permissions.

Select the file, choose Properties in the file drop down menu, select the 'security' tab, then tick the override security. You can then select people or groups from the drop down list, add them to the list, then you can choose to allow or deny the read / write / delete permissions.

Of course you may then need to reverse the above. Of course having made a change to the file it will no longer be in synch with the item master - so putting the item back to WIP is usually safer. Another way to achieve this goal would be to create a simple file lifecycle with two states on it and use this to unlock files. When you use Lifecycles and Item security together it is a 'last one wins' model. Mikel Martin Autodesk Data Management Product Manager / Design Lead -----Original Message----- From: cadenza [mailto:cadenza] Posted At: Thursday, February 04, 2010 8:16 AM Posted To: autodesk.productstream Conversation: Manually lock and unlock files Subject: Re: Manually lock and unlock files They have taken that functionality away!

You can set the item linked to the file back to WIP which will unlock the file or if you have admin rights you can change the file properties to allow a specified person group to open the file, The 'locking' is actually denying you write permissions. Select the file, choose Properties in the file drop down menu, select the 'security' tab, then tick the override security. You can then select people or groups from the drop down list, add them to the list, then you can choose to allow or deny the read / write / delete permissions. Of course you may then need to reverse the above.

Of course having made a change to the file it will no longer be in synch with the item master - so putting the item back to WIP is usually safer. I tried the security route. I wanted to lock down a project file, so as the administrator I went to properties>security and overrode the security allowing only administrators the ability to modify or delete the file. All others could only read. So I tested it. The first thing I did as a normal, non-admin user was to try to change the state of the file (btw.the file showed a lock icon as if it were locked). Yep, I could change the state.

What happend to the security override??? I changed the state back and then the file became unlocked. So I went back into the client as an administrator and saw that the security was no longer overridden. So, thinking maybe I messed up.I tried it again, with the same result. Why did Autodesk remove a feature that was so convenient before???? Off to create a separate lifecycle just to handle locked files. The Change State command always has to be available for both locked and unlocked files.

Otherwise you could lock a file by putting it in released state and never get it out of that released state. After some planning, the security can be configured appropriately so that only the right people can make those modifications to the file. For example, you can configure the lifecycle definition to only allow certain people the right to make certain state changes or to have access to files in certain states. I suggest looking at the transition security on your system. The system is very configurable and can be a very powerful tool.

As for document and item lifecycles being used together, it certainly can be done, but many users choose to drive the security through one system. For example, you can drive lifecycle states and security through the document lifecycles but still use Items for BOM data, ERP integrations, etc. Regards, Adam. Adam, I appreciate your response.

Locked should mean locked, regardless of state changes. No change is allowed.not even a state change. The administrator can apply the lock and remove the lock. If the administrator applys the lock, then the ramifications of such lock would be realized when it comes to state changes. Security has been properly configured through transisitions.

I only want an administrator to be able to modify a locked file. Some users (the advanced group) are allowed to change state (example: from Released to WIP). But even these need to be prevented from changing some files like the ONE project file that everyone's projects hinge on. I can't risk this being modified (even by myself). I filed a support ticket with Autodesk Subscription. This was the technical question, 'You've removed lock file capabilities from vault (that existed previous to 2010), now what?' The support representative was very friendly, but pointed me to the forums because 'this is not a technical issue'.

There is NO formal documentation from Autodesk anywhere on this! While talking with him, I had an idea. Instead of creating a separate lifecycle altogether and having to worry about recategorizing or reassigning files to a different lifecycle, Why don't I just create a separate state in the lifecycle called 'Locked' and only allow Administrators to transition in and out of that state. Sounds easy.I'm going to try it.

Why couldn't this have been documented as an 'alternative way' of locking files? Locking files by transitioning to a 'Locked' state works great! I've assigned the Administrator group as the only ones allowed to transition in and out. I'm considering creating another stated call 'Locked and Released' as an extra tool for administrators who want to lock a released file but keep it in a released state so other parent files can be released.

(the locked state would be a 'released state') This will be necessary if you mandate that children be released before their parents. I haven't tried it yet, but it seems like it should work. Honestly though, it's nice to have these tools available to the administrator, but right now I can see a time we would use them. The whole driving factor for all of this was so I could do one thing.lock the project file. I hope someone finds this useful.