Update to /api/barcode/po-recieve/ error messages

[Idea-Junkie]

Includes

Updates to barcode error messages, letting users know if a barcode was found with a plugin, and what is missing from that information.

Example: PO found, Supplier part Not found

See more in #11361

No Supplier Associated to Plugin

Also added "no_supplier_plugin _error" to notify the user if plugins do not have suppliers set in settings

This is set to only pop up if there is an error, if a match is found it skips this step

List of Tasks for this to be a Completed PR

• Documentation Update
• Error Message implementation
• Add Unit Tests
• Pre-Commit Style Verification

[netlify]

✅ Deploy Preview for inventree-web-pui-preview ready!

Name	Link
🔨 Latest commit	c20be4a
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/69a06b2540ea7600099fb81a
😎 Deploy Preview	https://deploy-preview-11369--inventree-web-pui-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 92 (🔴 down 1 from production) Accessibility: 81 (no change from production) Best Practices: 100 (no change from production) SEO: 78 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Idea-Junkie]

@matmair I will be making the documentation edits on here as well which is why its a PR draft.

I believe this was a good first issue for me to get my feet wet, and I hope to be more of assistance on some other issues.

any comments on how I went about this? Should I work on it and then make a PR draft request and include the conversation in there instead of how I did it with the discussion? or is the discussion a better method?

[matmair]

Looks good in general; a few smaller things to address

I will allow CI now to see if there are style issues etc.

[matmair]

any comments on how I went about this? Should I work on it and then make a PR draft request and include the conversation in there instead of how I did it with the discussion? or is the discussion a better method?

making generalized rules is hard; if it is a concrete change or widening to/of system behavior, a feature request with "I want to dev this" selected is the way to go. That allows us more concrete roadmap management and improves visibility to the change and that someone is working on it.

Small things can just be done and PR'ed (with sufficient PR description). If the thing will take you longer than 1 week to dev I would certainly open an issue or discussion to ensure you do not waste time on duplicate / unwanted things.

[Idea-Junkie]

Updated the requests you made, let me know if there is anything else I need to add or change, as the workflow changed a little bit with the changes your requested.

Also updated documentation (was only like two notes really)

Also while Im at it, is there a way to make the images on the documentation smaller? Its always overblown for me on my desktop because its a vertical picture instead of horizontal, also tried to preview it in VScode but it just showed how the text would work.

[matmair]

LGTM; adding some test coverage would be good too

[SchrodingersGat]

@Idea-Junkie looking good in general -are you going to add support for these messages to the app, too?

[Idea-Junkie]

@SchrodingersGat

Mobile Error Pop-Up

The original line was too long but with a carriage return added to it, it is readable on the app as well

is this what youre talking about?

[SchrodingersGat]

@Idea-Junkie yes, perfect!

[Idea-Junkie]

I believe this is ready for a commit now, Unless we think the tests would be necessary.

[matmair]

Not really a fan of such changes without coverage, but I will defer to @SchrodingersGat for judgment if adding / extending them is required in this case

[codspeed-hq]

Merging this PR will degrade performance by 6.89%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

❌ 1 regressed benchmark
✅ 43 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	test_api_list_performance[/api/stock/location/]	19.6 ms	21.1 ms	-6.89%

---

_{Comparing Idea-Junkie:More-Barcode-Error-messages (5abadba) with master (246108e)¹}

Footnotes

1. No successful run was found on master (8a4ad4f) during the generation of this report, so 246108e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[codecov]

Codecov Report

❌ Patch coverage is 72.00000% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.96%. Comparing base (8a4ad4f) to head (5abadba).

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11369      +/-   ##
==========================================
- Coverage   87.99%   87.96%   -0.03%     
==========================================
  Files        1295     1295              
  Lines       58793    58831      +38     
  Branches     1938     1938              
==========================================
+ Hits        51733    51752      +19     
- Misses       6578     6597      +19     
  Partials      482      482              

Flag	Coverage Δ
backend	89.15% <72.00%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Backend Apps	91.65% <72.00%> (-0.05%)	⬇️
Backend General	93.37% <ø> (ø)
Frontend	70.81% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SchrodingersGat]

I would definitely want to see some unit tests here. This barcode scanning to receive parts has gone through a number of bug-fix cycles already and it's very hard to trace down errors "in the field" because of the interplay between the different systems.

So at the very least, some additional unit tests to cover the new modes of operation / expected error codes

[Idea-Junkie]

Ok, I will take a look at adding more unit tests. Thank you guys for your guidance and help with this!

[Idea-Junkie]

Would this apply to [src/backend/InvenTree/plugin/builtin/suppliers/test_supplier_barcodes.py? or src/backend/InvenTree/plugin/base/barcodes/test_barcode.py?

EDIT: Found in https://github.com/inventree/InvenTree/blob/master/src/backend/InvenTree/plugin/builtin/suppliers/test_supplier_barcodes.py