8.1 Room Worksets

[janunson]

I have 2 users in a workset project. they have made only 2 worksets, one for each of them. The project has room tags where some of them have a room workset user A, some have a room workset user B. Now user A cannot edit the room schedule without sending a separate edit request to user B for each room user B placed. I want to move all room worksets to another workset or otherwise solve this problem. I selected all room tags and did the 'Make Editable' command and this didn't do it. Also checked out room tags and project parameters worksets. What am i missing. is there a way to change the room workset?

TIA!

[aaronrumple]

The "room" object is created when the tag is placed. It is a series of bounding lines which are invisible except when you select the tag and you see the red bounding line. The "room" object is placed on the current active workset. The tag is part of the view workset.

In my experience it is best to have the "room" object in the same workset as the bulk of the walls it is constructed from. This way you are less likely to bump into someone while working.

To update the "room" object workset, just make the current room object workset active. You'll also need the view workset of the tags editable. You can then grab the room tags and change the room workset to whatever makes sense for that group of rooms.

In my opinion, rooms should be "worksetless". Since they are not visible and only follow other objects in the plan around and cannot be directly editable, the workset assignment is meaningless to the end user. (I'm sure the programmers had a good reason...)

[Wes Macaulay]

Some of our users have created a Rooms workset which they would set current when tagging rooms. Then they could readily edit the rooms (room finishes and so one) by setting the workset current and making it editable.

I don't think it will matter any more in 8.1...

[LRaiz]

Aaron is correct in pointing out that room tags live in view worksets while rooms themselves live in one of modeling worksets. Even though room tags workset membership is not under user control, it is possible to change workset of a room.

Making rooms workset-less (as Aaron suggests) may have negative side effects. On the other hand I agree that there should be an easier way for users to change room worksets. Enhancing schedules to allow editable workset column (especially for room/area schedules) may be a good solution.

[irwin]

is there a way to change the room workset?
In order to change the room workset, select a room tag corresponding to that room and go to Properties. At the bottom there are two parameters "Tag Workset" and "Room Workset". The former is set to the view workset of the tag and can't be changed. The latter can be changed to put the room in a different workset. You can change the worksets of several rooms at once by selecting several tags at once and going to Properties.

There's no doubt that rooms can be confusing, even without worksets. They are invisible elements that are automatically created when you place a room tag; or, an existing room is invisibly grabbed when a new tag is place in it. None-the-less, room elements are not view-specific, are not part of families, and are not project standards, and are treated accordingly for purposes of workset assignment.

I don't see any real alternative to the current workset placement of rooms. Room elements contain real information settable by the user, such as the room name. You don't want to let two different users change this information at the same time so there has to be some workset to establish ownership. (With element borrowing and transparent permissions, a case can be made that workset ownership no longer matters; if you are working that way then it doesn't matter what workset the rooms are put in.) Putting the room in the view workset of the tag wouldn't make sense because there can be several tags from different views referencing the same room -- you can even delete the view in which you placed the first tag and the room lives on. The room can't be put in the workset of the walls that bound it because those walls might not all be in the same workset. If the rooms were put in either a new room project standards workset or the tag family workset then you couldn't have different people editing rooms in different parts of the building simultaneously. (Well, you could using element borrowing, but if you're working that way then again it doesn't matter what workset the rooms go in.) So, room elements are handled in the same way as all other non-view-specific elements in the building -- they are put in whatever workset is active when they are created. This gives the flexibility to organize them according to the way responsibilities have been divided among team members on the project.

[janunson]

Thanks for the replies everyone. My problem was i had to kick everone out of the file, so i could check out all the worksets (rooms had been placed on several) so that it would enable the room workset property in the properties box.

Here's something that might make this easier. It appears that currently, although i can borrow an element from another workset, i cannot change its workset to another one unless i have checked out the whole workset from which it is a member. It would be cool if i could borrow an element and change its workset. I realize that it'd probably require a save to central, but that's not that unusual when borrowing elements anyway, in my experience.

Also reminds me of a wish that i'll go bump - workset paintbrush
http://forums.augi.com/showthread.php?t=25273

[irwin]

It appears that currently, although i can borrow an element from another workset, i cannot change its workset to another one unless i have checked out the whole workset from which it is a member. It would be cool if i could borrow an element and change its workset.
Actually this isn't quite true. You can change the workset of a borrowed element -- you don't have to have the whole workset editable. The problem is, you must make the element editable _before_ you change its workset. Select the element(s), right click, choose Make Elements Editable. Now you can go to properties and change the workset. I see two problems with the current implementation (8.1):
1) When you open Properties of a non-editable element, it lets you change the other properties of the element and then automatically borrows the element for you. Why won't it let you change the workset property and automatically borrow? I'd say that's a bug.
2) This bug is particularly annoying in the case of a room element, because there's no way to select the room itself to do Make Elements Editable on it. Selecting the room tag doesn't do any good, since it isn't the tag you want to make editable. One workaround for this is to change some other property of the room -- this will then automatically make the room editable. For example, type something in the Comments field in Properties, and press OK; note that when you go back to Properties the room is editable so the Room Workset field can be changed. But what if you don't want to change any other properties of the room. Here's a trick to do that. Please fasten your seat belts. After changing the comment and pressing OK, press Undo. This will undo the change to the comment. But, it will leave the room Editable! This is because a change of editability is a change to the central file record of ownership; when you undo it undoes the operation in your local file, not the change of ownership that accompanied it. This is not a bug, but is the intended behavior, consistent with similar operations. Just as undoing past a Save doesn't erase the file you just saved on disk, so undoing a make-editable doesn't relinquish. (Admittedly this is pretty subtle.)

[janunson]

... there's no way to select the room itself to do Make Elements Editable on it. ...type something in the Comments field in Properties, and press OK; note that when you go back to Properties the room is editable so the Room Workset field can be changed. Then press Undo. This will undo the change to the comment. But, it will leave the room Editable.
Good tip! Thanks!