[mobile] Scanning API fixes
- In a Stock Entry or Repack context when an item is scanned, the
add_or_incrementfunction does not call the appropriatedetailsAPI to get the rest of the information. - the
routeand filter` functions need to call the API to refresh the list.
@agritheory I think I'll need more context on both these points.
In a Stock Entry or Repack context when an item is scanned, the add_or_increment function does not call the appropriate details API to get the rest of the information.
Do you have an example component I can check for the setup?
the route and filter` functions need to call the API to refresh the list.
Should it always go to the same route, or be configurable to go to other routes per scan-type?
Regression on however this is exposed:
Do you have an example component I can check for the setup?
https://github.com/agritheory/beam/blob/version-15/beam/beam/scan/init.py#L162
Should it always go to the same route, or be configurable to go to other routes per scan-type?
If the scan action from the listview is "route", it should change the route, otherwise I think we should implement the reactive list filter here as well. UI work: https://github.com/agritheory/stonecrop/pull/179
@agritheory
Regression on however this is exposed
So the onScan.js instance is mounted on the window object, which means that simulating on any non-window object will throw that error. I'm not sure what the right solution here is: should the implementation file decide where to mount the instance instead?
The following should work for you currently:
window.scanner.simulate(window, '<barcode_string>')
If the scan action from the listview is "route", it should change the route, otherwise I think we should implement the reactive list filter here as well. UI work: https://github.com/agritheory/stonecrop/pull/179
Should the route maps be defined in hooks as well? Since the actual list of routes is defined there? We should probably have a 404 catch-all page as well in case a route somehow doesn't exist.
window.scanner.simulate(window, '<barcode_string>')
Ah, I am used to using document here but this makes sense.
Should the route maps be defined in hooks as well? Since the actual list of routes is defined there?
I don't think we need to do that. This is function of the scanning matrix unless I'm misunderstanding your question.
We should probably have a 404 catch-all page as well in case a route somehow doesn't exist.
Good idea, let's do it. I'll put in a ticket.
This issue isn't close to solved. Scanning does correctly interact with any ListView component at this time.
Oh my bad, I think I accidentally made it to be auto-closed after the PR was merged. I just wanted to connect this issue with the PR.
Partially resolved with #246
Filter needs to be implemented still.