Monday, January 17, 2011

Worksets - The Case of the Person is No Longer

It happens often enough, the person that Revit tells you "owns" something you need to deal with either isn't working on the project actively now or in some extreme cases doesn't even work at the firm anymore. Before I describe how to cope with this don't apply it to a team who has a rogue member who seems to borrow stuff and not return them all the time. That's a separate kind of issue, I'll address that situation at the end of the post.

Most often this missing person has a view, project standard or some other relatively "minor" element checked out. Otherwise it would have caught someone's attention sooner. One way to check for rogue users is to open the Workset Dialog, check all four Workset filters and scroll the list looking for usernames that shouldn't be there. This would be true even for regular team members if you are the only one in the project at the moment, say after hours for example.

When you need to remove a person that is no longer part of the team you need to write down the username(s) listed in the warning message that tells you "no, you can't have it because Bubba does".

Take the following steps if you are a timid Reviteer, this uses a Local File.
  • Open Revit (if it isn't already, don't open any files yet)
  • Close your own Local File (if Revit is already open)
  • Change your Username to match the missing person
  • Open the Central File, check the Create New Local File option (2010/2011)
  • You now have a local file assigned to this past user
  • Synchronize with Central (SwC)- relinquish all worksets
  • Close the Local File
  • Reset your Username - Open your previous local file
  • Resume work
Take the following steps if you are a brave Reviteer, this opens the Central File.
  • Open Revit (if it isn't already, don't open any files yet)
  • Close your own Local File (if Revit is already open)
  • Change your Username to match the missing person
  • Open the Central File (don't check the local file option)
  • You are now working in the Central File (most reliable if no other users are working in Local Files, if they Synchronize with Central while you are doing this Revit may insist on having you create a local file before being able to Synchronize with Central)
  • Synchronize with Central - relinquish all worksets
  • If there are other users involved - change your Username to match another
  • Repeat the process (again, other users might force you into a Local File, most reliable if no other users are actively working in the project)
If you'd like to take a brute force approach, definitely after hours, you can:
  • Open the Central file - Check the Detach from Central option
  • Save the file - provide a new name when prompted
  • You now have a new central file
  • Synchronize with Central - relinquish all worksets
  • Close the file
  • Have users create a new Local File based on this new Central File to begin work
If you have a co-worker that didn't relinquish everything before leaving the office the kindest/gentlest approach is to open their Local File on their PC and SwC for them.
  • This means you have to be able to log onto their PC as yourself
  • Change the Revit username to theirs if isn't already
  • Then you have to know where their Local File is, open it and SwC
  • Reset their Username
  • Close Revit
  • Log off their PC.
  • Let them know what you did! They'll probably see your log-on-name when they return and wonder.
You can also use either of the first two methods described above, as if they are no longer part of the team. The reason I suggest the kinder/gentler approach is that it protects any changes they made but didn't publish via SwC. That assumes they just saved the Local File but didn't opt to use SwC, which does happen from time to time when people get rushed off to a meeting or emergency. If someone is a repeat offender and shows no remorse you might consider the negative reinforcement of using the less kind and gentle approach.

Now if you are part of a big project, many central files and collaborating with other people that are referencing your files and theirs...slow down, take a deep breath. The same rule apply but before creating a new central file you'll need to consider file naming agreements. You'll also need to be mindful of who else is cranking away on the project when you decide to deal with this situation. Go slow, methodical...the turtle may win this race as opposed to the rabbit creating some havoc.

...elementary my Dear Watson!


Matthew Gonzalez said...

Good tips there Steve, this happens quite often to us when an engineers is in the beginning stages of getting to know Revit. The only "gotcha" I would add to this is that once you have manually overwritten the user name it will no longer automatically be whatever the Windows login name is. If there is only one person that ever uses that particular computer then this probably doesn't matter, but if it does matter to someone, this is how I've found to fix this behavior (hope the indenting shows up correctly):

1. Close Revit.
2. Locate the Revit.ini file on the workstation.
For 2011 the default location is: C:\Program Files\Autodesk\\Program.
For 2010 or earlier it is: C:\Program Files\\Program.
3. When the username is overridden the following 2 lines are added to the Revit.ini file:
[Partitions] Username=X
You can search the file for this; the X above designates the specific username.
4. Remove both lines from the Revit.ini and save.  When the next user, and subsequent users log onto the workstation Revit will pull the Windows username.

Clay said...

Be careful with the "brute force" approach. Your new central file won't carry over all the recovery/backup files from the old one. If you HAVE to do this, make sure you archive the old file AND it's backups FIRST. Especially if you want to keep the central file with the same name. ;)

Dave Baldacchino said...

I guess the brutest (is that a word?) approach is to dump the .slog file if no one is currently working. Use at your own risk :)