8.1 "Editable only"

[Nic M.]

The "Editable Only" in the option bar is in 8.1 default off.
I can set it to on but after a command finishes it goes back to off
Is there another option to "lock" some workset during a session?

I use worksets to separate the architectural part of a building from the electrical part
When I work on an electrical plan I find it reassuring not to be able to alter a wall / door.

[Wes Macaulay]

Prior to 8.1, if you hit Esc with no object selected, "Editable Only" deselects! :banghead:

Now that objects are transparently selectable, they've reversed this. I didn't understand your question before, but I see your point. How is this going to be a problem for you?

[Steve_Stafford]

Nic,

Up until this release Revit checked this box by default as you say. You are the victim of other user's requests my friend. Asking for it to be Un-checked by default has been a top 5 workset question among folks I've worked with. One person called it his nemesis...

We wouldn't be able to have the kinder gentler worksets if it were checked by default. The assumption now is that we shouldn't be bothered with warnings and prompts if the object is "busy" but available. The only way we get confronted is if someone actually borrowed the object already.

[Nic M.]

I'm pretty sure in previous releases it was the other way around.
I understand and love the smoooth worksets. But I have my doubts on the ability that every user can poke around in grids, levels, ...
I think some level of security / permissions is necessary.
Maybe not that much in my example but in large projects this maybe an issue.

[Steve_Stafford]

...I'm pretty sure in previous releases it was the other way around...Yes you are right...prior to 8.1 the box was checked by default. Now it is not...and many people I've met will be happy about it.

If you are concerned about limiting access to certain types of things in your projects create a new local file after changing your workset username to Admin. Now this local file will belong to "user" Admin and this "user" can check out worksets that grids, levels, whatever you choose are assigned to. STC and don't relinquish these worksets. Now return to your own local file and continue working. Now it will take extra effort by another user to undo this, a little road block.

[Wes Macaulay]

Ah, Evil Steve, you've done it again!

Smokin great tip...
:veryevil:

[Nic M.]

My only reason to use worksets was to be able to lock some part of the project at some stage in the projects live. Just to make sure that when a projects gets more interior detail the core / outside is locked down. Because I'm a one man band I can do that. I understand that on a multi user project this is not the preferred method.
In the past I had used design options for this but then someone told me worksets was the way to go (Aaron ;) )
Maybe I can post a wish for putting it back "on" Lets do a poll :rolleyes:

[irwin]

If you are concerned about limiting access to certain types of things in your projects create a new local file after changing your workset username to Admin. Now this local file will belong to "user" Admin and this "user" can check out worksets that grids, levels, whatever you choose are assigned to. STC and don't relinquish these worksets. Now return to your own local file and continue working. Now it will take extra effort by another user to undo this, a little road block.
No need to create a separate local file. Just close all files, change user name to Admin, open central, check out worksets, close central without relinquishing, change user name back to your user name (never change your workset user name while there is an open file). Also note, this won't keep others from adding new elements to these worksets, but will keep them from changing the elements that are already there.

[Steve_Stafford]

...No need to create a separate local file. Just close all files, change user name to Admin, open central...aah...but were trying to keep folks from opening the central file right? :wink: Good habits eh? Now that I'm done being picky, I know that you were talking to Nic as a single user...

[Wes Macaulay]

I dunno Steve -- maybe his tactic is OK on a multiuser project if you haven't made any changes?

[david.kingham]

I would create two seperate files, one architectural and one electrical and simply link them into each other. It has worked rather well with structural for us, seems alot easier than this elaborate workset workaround. but maybe there is something i'm missing.......

[Steve_Stafford]

I dunno Steve -- maybe his tactic is OK on a multiuser project if you haven't made any changes?During office hours it is a bit risky to assume that nobody else will open their local file, unless you tell everyone not to and make sure they don't have it open still, so you can open the central and do this. I took the "safe" road in my description.

[irwin]

During office hours it is a bit risky to assume that nobody else will open their local file, unless you tell everyone not to and make sure they don't have it open still, so you can open the central and do this. I took the "safe" road in my description.
I'm afraid I don't follow you, Steve. What's wrong with someone opening a local file while you have the central file open? This is intended to work.

[Steve_Stafford]

I'm afraid I don't follow you, Steve. What's wrong with someone opening a local file while you have the central file open? This is intended to work.Now I don't follow you...every tech support person I've talked with and implementation person I've met has insisted that we should not work in the central file, only our local file. Are you saying that is not valid? I can work in the central file while others are working in their local copies?

[irwin]

Now I don't follow you...every tech support person I've talked with and implementation person I've met has insisted that we should not work in the central file, only our local file. Are you saying that is not valid? I can work in the central file while others are working in their local copies?
There are some issues to keep in mind, but as far as I know working in the central file should work.

First, here's what happens if you make changes in the central file and someone else saves to central while you are doing that. When you try to save the central file, it detects this and won't let you directly save to central. But the resulting dialog tells you what to do in this case -- save the central file as a local file and then save to central. You don't lose your work and you don't overwrite anyone else's work. No harm done, just one extra step required.

I think the main reason that working in the central file is discouraged is that if you have a local file with changes in it and at the same time you make changes directly in the central file with the same user name then your local file will be invalidated. (The same problem will occur if you work in two different local files using the same user name.) If your users can be careful to avoid doing this then there's no harm working directly on the central file. Some people discourage work on the central file altogether to prevent this situation. You have to decide for your particular work environment if the users would be better off with the simple rule "don't work in central" or they can be trusted not to edit the central file while having a local file with the same user name.

[Wes Macaulay]

Another must-read post from the founders!

Thanks a bunch for the clarifications -- I knew about the central file requiring a re-save as a local but didn't know about this particular method of orphaning the local file.

One other reason we've given around here is that if you have a save that goes really badly while you're working in the central file -- you could be hooped. There's no Central File.001 file -- they're all workset streams -- so if you completely blow up the central file you have no local file to resave as central (or central file to recreate the local file). Having blown up several local files and one or two centrals I'd probably still recommend people not work in the central file directly unless they have an up-to-date local file.

[Steve_Stafford]

...Another must-read post from the founders!...I agree!


There are some issues to keep in mind, but as far as I know working in the central file should work.Thanks for clarifying. I see now that the rationale for recommending "we" stay out of the central altogether, appeals to the "lowest common denominator" of predictable behavior. "We" don't have to "worry" if "we" don't edit the central directly.

I think THIS WISH (http://forums.augi.com/showthread.php?t=11281&highlight=workset+local) would make the work flow "safer" and more "rational".

If there are two Steve's or "Wesley's" working on the project, can this contribute to errors like you describe because of the "same" username? Does Revit apply a unique ID to each username, that we just don't see?

[irwin]

One other reason we've given around here is that if you have a save that goes really badly while you're working in the central file -- you could be hooped. There's no Central File.001 file -- they're all workset streams -- so if you completely blow up the central file you have no local file to resave as central (or central file to recreate the local file). Having blown up several local files and one or two centrals I'd probably still recommend people not work in the central file directly unless they have an up-to-date local file.
Note that when you save the central file all the information necessary to reconstruct the backup files is saved in those workset streams. You can use rollback or extract backup to get at it. Saving a new version of the central file doesn't touch the files needed to reconstruct the backups (except that it purges the oldest backup). I know that people are naturally less trusting of these mechanisms than they are of just renaming a non-workset file backup that they can "see and touch" but they do work. That said, of course having an additional local copy on a different machine adds yet another layer of safety.

If there are two Steve's or "Wesley's" working on the project, can this contribute to errors like you describe because of the "same" username? Does Revit apply a unique ID to each username, that we just don't see?
The Revit user name is just the string of characters you see -- no unique ids in the background. Haven't you ever "impersonated" another user to kick him out of some workset you want to edit? :evil:

[Steve_Stafford]

The Revit user name is just the string of characters you see -- no unique ids in the background. Haven't you ever "impersonated" another user to kick him out of some workset you want to edit? :evil:What I meant was, would Revit object to to users having the same workset username? I've never tried it...does Revit know that this Steve and that Steve are really different users?

[irwin]

What I meant was, would Revit object to to users having the same workset username? I've never tried it...does Revit know that this Steve and that Steve are really different users?
If two users both have the same workset user name then Revit will think they are the same user. When one Steve makes something editable, the other Steve will be allowed to change it (he is effectively impersonating the first Steve). When the first Steve goes to save to central he might not be allowed to because he and the other Steve changed the same element. As far as Revit is concerned it's as if you made changes in two different local files with the same user name -- a definite no-no.

[Steve_Stafford]

Okay, thank you! Understood!

[Wes Macaulay]

I had wondered, but never been crazy enough to try that...

Thanks again, Irwin!