Project File A has a separate workset for Project File B and that file is assigned to it. Both the linked file's instance and type parameters are assigned to the same workset. User A is the Owner of Project File B's workset. Now User B is working in their own local file and decides to close the Project File B workset (instead of using the Manage Links > Unload method). User B gets a warning that User A owns the element.
When we expand the warning we see that the file is the issue.
User B clicks Cancel and the workset closes, the link is no longer visible (the desired result despite the message). If User B Opens the workset, no error. The error only occurs when the workset is closed.
Closing a workset that has a linked file associated with it now is equivalent to using Manage Links > Unload, because using unload generates this error message now too.
This error dialog is very confusing because it claims that we can't do something, without creating an Editing Request, that clicking Cancel does let us do. We now have a normal error message that we have to tell users they can ignore, click cancel please. That's just ridiculous.
Demand loading and unloading worksets is fundamental and critical for large projects. Large projects have many people contributing so now we'll have many people getting a pointless message.
2 comments:
In the past I will place the instance for the Model and place it on the linked model workset which I then take ownership of to avoid movement. I place the type for the model on workset 0 so that it allows users to be able to reload the model if they need to. Maybe this would work avoiding this issue
Thanks, it does seem to mitigate the issue. In the past I've seen visibility control conflicts arise when they are assigned to different worksets. They intended them to be able to have different workset assignments per instance so we'll have to see if it helps in the long run.
Post a Comment