Traceback
```
Error: Python: Traceback (most recent call last):
File "\bonsai\bim\ifc.py", line 443, in execute_ifc_operator
result = getattr(operator, "_execute")(context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\bonsai\bim\module\pset\operator.py", line 126, in _execute
ifcopenshell.api.run(
File "\ifcopenshell\api\__init__.py", line 92, in run
return usecase_function(ifc_file, should_run_listeners=should_run_listeners, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\__init__.py", line 252, in wrapper
result = usecase(*args, **settings)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 166, in edit_pset
return usecase.execute()
^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 176, in execute
existing_props = self.update_existing_properties()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 225, in update_existing_properties
prop = self.update_existing_prop_enum(prop)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "\ifcopenshell\api\pset\edit_pset.py", line 251, in update_existing_prop_enum
primary_measure_type = prop.EnumerationReference.EnumerationValues[
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'EnumerationValues'
```
Noticed working on #5596 and #5708 a few issue when pset template is changing the prop types.
E.g. prop had string data type and now template suggests that it should be a float.
Previously, it might error trying to cast a string to a float. Now it will show a float until user will set it to null, then next time it will be loaded from the template data type.
Another example - prop was a string and now it's a boolean. Previously, it would be cast to boolean implicitly. E.g. "test" -> bool("test") -> True. And if user wouldn't be paying attention then enabling pset editing and saving it would make them lose "test" value.
Now - https://imgchest.com/p/na7ke99wb78
Before - https://imgchest.com/p/5xy23rr3z4l
It was leaving an orphaned pset if 'products' was a list of all elements pset is assigned to. Then it would create a new pset for each element leaving original pset orphaned.
In IFC it's possible for a property set to be assigned to multiple elements and which may lead to confusing behaviour when you edit a pset on one element and other element seems to get edited too.
Which makes it worse is that that it is possible that some software is might be doing this unintentionally when exporting IFC (as some sort of optimization as storing 1 is more optimal than n copies of it).
So now there are some tools in Bonsai and in IfcOpenShell to handle the shared psest:
1) Indication that property is shared - https://imgur.com/a/9dd3jST (similar to how Blender indicates ID data-block users). You can click on it to "unshare" the pset - a new copy for the pset will be created and it's going to be linked only to the active object.
2) api pset.unshare_pset method that does the same. And util.element.get_elements_using_pset method that encapsulates schema differences and different approaches for occurrences/types.
3) ifcpatch recipe 'UnsharePsets' that's making all property sets in the IFC file to have just 1 element that's using them. You can limit the affected elements by providing query.
ifcpatch recipe is also available in Bonsai - https://i.imgur.com/aOCx7HI.png
Kind of experimental. The idea is that it will reassign class e.g. from IfcWindow to IfcWindowType (or vice versa) and will keep the IFC representations and property sets.
Example - https://imgur.com/a/X7MHR0s
1) For psets there was an issue - it was instantiating abstract IfcProfileProperties
2) For materials it was only able to instantiate IfcExtendedMaterialProperties though there are other pset types too in ifc2x3.
Bruno Perdigão
