IDS wrong auto conversion

[Can-Gr]

Describe the bug 📝

I’m checking a dataType=”IFCTEXT” in my IDS for my value. So it should be checking String “410.20257“. But IDS check converts this requiredValue automatically to number and checks for 410.20257 then the test fails because 410.20257 ≠ “410.20257“.

Can you help on this matter ?

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

"@thatopen/components": "^3.4.1",
    "@thatopen/components-front": "^3.4.1",
    "@thatopen/fragments": "^3.4.1",
    "@thatopen/ui": "^3.4.0",
    "@thatopen/ui-obc": "^3.4.0",

Used Package Manager 📦

npm

Error Trace/Logs 📃

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
• Check that this is a concrete bug. For Q&A join our Community.
• The provided reproduction is a minimal reproducible example of the bug.

[agviegas]

Fixed on main, shipping in the next patch (@thatopen/components 3.4.7).

The cause was type coercion at IDS import: the XML parser turns a numeric-looking <simpleValue> (e.g. 410.20257) into a JS number, and the value facet then compared it strictly (===) against your IFC property value, which for IFCTEXT is a string "410.20257". The comparison only stringified the required value for IFCLABEL, so IFCTEXT (and IFCIDENTIFIER) fell through and always failed.

Now the facet value is compared as a string whenever the actual property value is a string, so IFCTEXT string values match correctly. Numeric comparisons are unaffected.

Thanks for the report. Closing as done. If it's still off once the patch is out, let us know and we'll reopen.