I trying for a script to change the work-set of elements in group to another work-set with a condition filter by "System Classification" if it satisfied then change the work-set of those elements.
I don’t believe you can actually change the workset of elements within a group (I could be wrong). Rather you can change the workset of the group itself which will change the elements associated with the group. Here I used Clockwork’s Element.SetWorkset node to set the group’s workset. Hope this helps!
The process which, I showed in that .pdf which is happening in Revit. But one drawback, if we change element or element properties in a group it needs to reflect in other instances also right. But this rule is not applicable in this case. I tried to make that instance copy but also it’s not working.
It is hard to come up with a suggestion if we don’t know what your (end) goal is.
But i think you have come up with a different workflow, as ALL the Elements in a Group are allways in the same Workset as the Group.
A different workflow could be a Instant Parameter which can vary per Group instance.
This looks like a great way to corrupt a model. It uses a known bug to circumvent the intended structure of groups (all workset info is stored at the host level, not the element level), where grouped content is placed in the active workset when created in group edit mode. Effectively only the first instance will get the dual workset group, and all future group instances will revert to the group’s host. Not sure if/how the existing secondary instances work here.
You may see the mix maintained long term without issue, or it could revert back to that of the group instance after something like an open with audit command, or it could go corrupt and you’ll be down and unable to open your project.
Generally speaking groups in groups are a last resort as their transforms and parameter values get overly complex, so I recommend not doing it and sticking to only single level group instances.
