View's Workset Editable - Change from No to Yes with the API?

[J33C316]

Can anyone tell me if it's possible to change a view's workset status from "No" to "Yes" (editable) using the Revit API (Revit 2023 or earlier). See image blow.

I'm not asking to have anyone do my work for me. I just want to know if it's possible and maybe toss me a hint or two? I've searched the internet and I've found several similar posts saying it wasn't possible but they were for much older versions of Revit. 

Thanks in advance!

[J33C316]

Can anyone tell me if it's possible to change a view's workset status from "No" to "Yes" (editable) using the Revit API (Revit 2023 or earlier). See image blow.

I'm not asking to have anyone do my work for me. I just want to know if it's possible and maybe toss me a hint or two? I've searched the internet and I've found several similar posts saying it wasn't possible but they were for much older versions of Revit. 

Thanks in advance!

[jeremy_tammik]

I asked the devteam for you.

[jeremy_tammik]

I asked the devteam for you.

[J33C316]

Thanks Jeremy. I think they are read only and can’t be changed using the API but we’ll see what they come back with.

[J33C316]

Thanks Jeremy. I think they are read only and can’t be changed using the API but we’ll see what they come back with.

[RPTHOMAS108]

When you take ownership of a workset it becomes editable to that user 'Yes' and when you relinquish the workset it reverts to 'No' (which doesn't actually mean you can't edit it).

WorksharingUtils.CheckoutWorksets allows the user to take ownership of the workset and make them editable to that user.

WorksharingUtils.RelinquishOwnership allows user to decide via RelinquishOptions what is relinquished (given back) including various workset types.

I believe the 'editable' indicator is just a function of if the current user has taken ownership of a certain workset or not i.e. they can take ownership of a workset for whatever time period to be sole editor of it until they relinquish it. The 'Yes/No' is only meaningful when you are the owner of it. The interface is probably outdated and contains bad terminology to a certain extent. The default is 'No (Non Editable)' meaning everyone can edit items on a workset via borrowing elements (so 'non editable' means you can edit it and so can everyone else).

I believe the only other time it is 'yes' is when you've just created a workset but are yet to synchronise it to central. You can't make it 'non editable' available to all users until after you've synchronised it (because it doesn't yet exist in the central file). So under that circumstance you would have to synchronise then relinquish. Similarly if you wanted to rename a workset you would have to make it 'editable' first.

So in summary the 'Editable/Non Editable' aspect should be read as relating to if current user can solely edit the workset or not rather than just being a borrower of elements on a workset.

The 'Owner' column exists separately from the 'Yes/No' one because some types of workset you decide to be the editor/owner of (user created ones) whereas when you create a view the ownership of the view workset is inherently you until synchronised.

[RPTHOMAS108]

When you take ownership of a workset it becomes editable to that user 'Yes' and when you relinquish the workset it reverts to 'No' (which doesn't actually mean you can't edit it).

WorksharingUtils.CheckoutWorksets allows the user to take ownership of the workset and make them editable to that user.

WorksharingUtils.RelinquishOwnership allows user to decide via RelinquishOptions what is relinquished (given back) including various workset types.

I believe the 'editable' indicator is just a function of if the current user has taken ownership of a certain workset or not i.e. they can take ownership of a workset for whatever time period to be sole editor of it until they relinquish it. The 'Yes/No' is only meaningful when you are the owner of it. The interface is probably outdated and contains bad terminology to a certain extent. The default is 'No (Non Editable)' meaning everyone can edit items on a workset via borrowing elements (so 'non editable' means you can edit it and so can everyone else).

I believe the only other time it is 'yes' is when you've just created a workset but are yet to synchronise it to central. You can't make it 'non editable' available to all users until after you've synchronised it (because it doesn't yet exist in the central file). So under that circumstance you would have to synchronise then relinquish. Similarly if you wanted to rename a workset you would have to make it 'editable' first.

So in summary the 'Editable/Non Editable' aspect should be read as relating to if current user can solely edit the workset or not rather than just being a borrower of elements on a workset.

The 'Owner' column exists separately from the 'Yes/No' one because some types of workset you decide to be the editor/owner of (user created ones) whereas when you create a view the ownership of the view workset is inherently you until synchronised.

[J33C316]

Hi Jeremy. Have you received an update on this subject yet? Thank you. 

[J33C316]

Hi Jeremy. Have you received an update on this subject yet? Thank you. 

[RPTHOMAS108]

Have you tried the WorsharingUtils class above for the View worksets in question?

Under certain circumstances described above you will not be able to influence this 'editable/non editable' aspect via the API for a single user because it is related to how two or more people are interacting in a workshared environment e.g if someone else owns the workset then you can only ask they relinquish it.

Choosing to take ownership of entire worksets is generally the old way of working before element borrowing was used. Mostly people take ownership just to do infrequent things such as change workset names but that isn't applicable to View worksets. They may also take ownership to restrict access but again not for views.

[RPTHOMAS108]

Have you tried the WorsharingUtils class above for the View worksets in question?

Under certain circumstances described above you will not be able to influence this 'editable/non editable' aspect via the API for a single user because it is related to how two or more people are interacting in a workshared environment e.g if someone else owns the workset then you can only ask they relinquish it.

Choosing to take ownership of entire worksets is generally the old way of working before element borrowing was used. Mostly people take ownership just to do infrequent things such as change workset names but that isn't applicable to View worksets. They may also take ownership to restrict access but again not for views.

[jonas.hoyerUGKDJ]

I don't know if this is still relevant for you but for everybody else who researches the problem in the future:
To set the editable status of the view workset to yes you have to check out the workset of the view by using the CheckoutWorksets method of the WorksharingUtils class. You can retrieve the WorksetId of the view with the ELEM_PARTITION_PARAM BuiltInParameter. Then you can construct a WorksetId with the returned integer and use that to checkout the views workset. That will set the editable status to yes. Hope this helps!

[jonas.hoyerUGKDJ]

I don't know if this is still relevant for you but for everybody else who researches the problem in the future:
To set the editable status of the view workset to yes you have to check out the workset of the view by using the CheckoutWorksets method of the WorksharingUtils class. You can retrieve the WorksetId of the view with the ELEM_PARTITION_PARAM BuiltInParameter. Then you can construct a WorksetId with the returned integer and use that to checkout the views workset. That will set the editable status to yes. Hope this helps!