mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-25 19:34:13 +02:00
b034d3c5b3
A slave and a terminal are both routinely separately orderable hardware. A circuit breaker can carry ten or twenty auxiliary blocks, each with its own order code, and a terminal block is a purchased part in its own right. Neither was reaching the bill of materials. Decided in discussion #847: @IBSYSLevi -- "I would not expect that a defined piece of hardware is excluded from BOM when not specifically defined as so" -- with use cases from @jozi332 covering Siemens breakers with ten to twenty auxiliary blocks and PLC cards carrying per-channel data. Two filters had to change, which is easy to miss: BomExport::defaultQuery() and, upstream of it, the WHERE clause of element_nomenclature_view itself. Changing only the query does nothing for slaves, because the view had already removed them. Terminals were already in the view, so they appeared as soon as the query allowed them -- which made a half-finished change look like it had worked. Measured on examples/industrial.qet, which holds 96 terminals and 41 slaves: 258 rows before, 354 with terminals, 395 with both. A slave given a manufacturer and part number now appears in the export; previously it could not, at any setting. Nothing that should stay out of a bill of materials is newly included. The folio report arrows and the conductor definition are still excluded because they are not hardware, and anything else -- a relay's own auxiliary contact, which is not orderable separately -- is kept out with exclude_from_bom, which the view already honours and which #721 and #765 made settable on the symbol itself. tst_smart_device is updated rather than weakened. @enesgursoy6110 wrote it in #830 to prove the filter works, inserting rows designated "Must not be exported"; the slave and terminal rows now carry real designations and are asserted present, and a folio report arrow takes over as the negative case, so the test still proves filtering happens -- at the boundary we now want. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>