Revit Workshaing - edited elements available for other users

[Anonymous]

Hi, 

I have set up worksharing for a project. We only have the 2 default worksets and they are both set to "no" under editable in the workset dialog box. We've created two separate local files. User A deleted an element, synchronized, and as user B synchronizes, the element is deleted in B's local file as well. All good so far. The problem is that when user A moves an element without synchronizing, and user B tries to delete/move the same element, user B is able to do so without having to place a request for user A. So something about ownership is not working. How to we fix this so we aren't able to change the same object simultaneously?

We've used worksharing for other projects and have not had this issue. 

Any ideas?

[cbcarch]

Sounds like User B is the "borrower" and can edit the element, which is expected behavior.

Open the Worksets dialog box to confirm.

[Anonymous]

Yes, but I thought that when one user is the borrower of an element, another user should not be able to edit the same element without placing a request? That is how out other workshared projects work and it makes sure that we are not messing in the same area at the same time. 

We did another test:

User A moves an item 2' without synchronizing

User B deletes same item without synchronizing (and doesn't get the message saying that User A owns this item, which is the problem)

Then we both synchronized, and User B got an error saying he could not synchronize because the item has been deleted

[Anonymous]

Sorry, I meant that User A who moved the item 2 ' got the message that he could not synchronize because the item has been deleted

I have verified that both users are in their local files and not the central

[ToanDN]

---

@Anonymous wrote:

Sorry, I meant that User A who moved the item 2 ' got the message that he could not synchronize because the item has been deleted

I have verified that both users are in their local files and not the central

---

That's how it always has been.  A reason to assign each person to work on a specific area so that they don't step on each-others' feet.

[Anonymous]

Although Im not super experienced with worksharing, I have to disagree with that. I ran the exact same test with a different workshared project, and after user A moves the item, user B cannot move or delete said item without placing a request to user A. User A owns the object until ownership is relinquished (during synchronizing). This does not happen in our newly set up project, and I cannot figure out why... Driving me crazy....

We're a small firm, doing small projects, so we do not have the need yet to split our buildings up into separate worksets, so we're keeping everything in our model on workset 1 for now. This has worked great so far, since the ownership of elements has been working as it should and stopping us from editing the same objects simultaneously. 

[ToanDN]

I read your statement again I realized you said User B could not "synchronize". I though you said he could not "move" the item already moved by user A, which is normal. So, yes it is strange.