[16.0][REF] shopfloor_reception: use generic "find" inside "scan_document"#1172
Open
nicolas-delbovier-acsone wants to merge 2 commits into
Open
[16.0][REF] shopfloor_reception: use generic "find" inside "scan_document"#1172nicolas-delbovier-acsone wants to merge 2 commits into
nicolas-delbovier-acsone wants to merge 2 commits into
Conversation
Contributor
|
Hi @JuMiSanAr, @mmequignon, |
Author
jbaudoux
reviewed
Jun 2, 2026
nicolas-delbovier-acsone
force-pushed
the
16.0-ref-shopfloor_reception-scan-document-find
branch
from
542ba9c to
b1ed091
Compare
jbaudoux
requested changes
Jun 3, 2026
jbaudoux
reviewed
Jun 3, 2026
mmequignon
reviewed
Jun 3, 2026
mmequignon
left a comment
mmequignon
left a comment
Member
There was a problem hiding this comment.
I agree on the the generic find, not on current's implementation.
This needs a little rework, I believe.
| "origin_move": self._scan_document__by_origin_move, | ||
| } | ||
| # only add the handler if scan_location_or_pack_first is disabled | ||
| if not self.work.menu.scan_location_or_pack_first: |
Member
There was a problem hiding this comment.
I understand this commit, but I believe you're fixing a non-issue.
And introducing a bug, as @jbaudoux stated in a comment.
We need to keep that order as it is in order to not break current's behavior.
Having if not handler: continue in scan_document is fine to me.
Or return {key: value for key, values in handlers_by_type.items() if value} ?
There was a problem hiding this comment.
I changed the implementation in order to keep both the filtering logic and keep the order of the elements in the dict.
Do you agree with this new implementation?
The `scan_document` processing step has been refactored to utilize the `find()` method from the shopfloor search action component. Previously, the logic manually iterated over the handlers and called the internal `_find_record_by_type` method directly, bypassing the broader search pipeline. By shifting this responsibility to the base `find` method, any standardized barcode preprocessing, custom resolution logic, or GS1-128 parsing injected into the search action component is now fully honored during reception. Furthermore, this provides downstream extending modules with a unified, singular hook point to alter or enrich barcode matching behaviors globally across the app.
… + documentation This prevents downstream logic from having to handle inactive handlers sequentially during scan evaluation.
nicolas-delbovier-acsone
force-pushed
the
16.0-ref-shopfloor_reception-scan-document-find
branch
from
b1ed091 to
8c56755
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
scan_documentprocessing step has been refactored to utilize thefind()method from the shopfloor search action component. Previously, the logic manually iterated over the handlers and called the internal_find_record_by_typemethod directly, bypassing the broader search pipeline.By shifting this responsibility to the base
findmethod, any standardized barcode preprocessing, custom resolution logic, or GS1-128 parsing injected into the search action component is now fully honored during reception. Furthermore, this provides downstream extending modules with a unified, singular hook point to alter or enrich barcode matching behaviors globally across the app.