Patch Sales Order line items progress bar to count fully allocated line items

[tomermurray]

Fixes #10945

This PR fixes an issue where the "Line Items" progress bar in the Sales Order list view would only increment when items were Shipped. It now correctly increments when a line item is fully allocated.

Implementation Details
Modified SalesOrderSerializer.annotate_queryset in InvenTree/order/serializers.py.

The previous implementation only counted lines where shipped >= quantity. The new implementation uses SubqueryCount with an updated filter that counts a line as "complete" if either of the following is true:

• The part is Virtual
• The line is fully shipped
• The line is fully allocated.

[netlify]

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

Name	Link
🔨 Latest commit	6756ae1
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/6964fd45b3725a0008d94df9
😎 Deploy Preview	https://deploy-preview-11102--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: 94 (🔴 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.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will degrade performance by 11.63%

_{Comparing tomermurray:so-progress-bar (6756ae1) with master (0134664)}

⚠️ 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.

Summary

❌ 2 regressed benchmarks
✅ 42 untouched benchmarks
⏩ 29 skipped benchmarks¹

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

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	test_search_performance[salesorder]	30.7 ms	34.3 ms	-10.36%
❌	WallTime	test_api_list_performance[/api/order/so/]	41.3 ms	46.7 ms	-11.63%

Footnotes

1. 29 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.10%. Comparing base (0134664) to head (6756ae1).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11102      +/-   ##
==========================================
- Coverage   88.11%   88.10%   -0.01%     
==========================================
  Files        1290     1290              
  Lines       58235    58237       +2     
  Branches     1969     1969              
==========================================
+ Hits        51311    51312       +1     
- Misses       6433     6434       +1     
  Partials      491      491              

Flag	Coverage Δ
backend	89.46% <100.00%> (-0.01%)	⬇️

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

Components	Coverage Δ
Backend Apps	92.02% <100.00%> (+<0.01%)	⬆️
Backend General	93.51% <ø> (ø)
Frontend	70.85% <ø> (ø)

🚀 New features to boost your workflow:

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

[matmair]

@SchrodingersGat this changes behavior; how should we document that?

[SchrodingersGat]

It now correctly increments when a line item is fully allocated.

"Correct" here is a matter of opinion - I would consider a line item only fully complete once it has been shipped to the customer.

Perhaps a different solution would be to annotate the queryset with an additional "allocated_lines" attribute, which could be used as an additional, separate column in the frontend table. So, the columns would be:

• Allocated Lines
• Shipped Lines

[tomermurray]

Thank you for the insight @SchrodingersGat

I fully understand and agree with you. It seems my personal workflow is divergent from the intended workflow, which is why I suggested the "fix", but I now see that it would cause breaking changes for the intended workflow. That said, for users who typically have a low number (1-2) of "Line Items" and "Shipments" per sales order, the two columns show essentially the same information, causing redundancy. I thus still think it would be worthwhile adding the "Allocated Lines" column.

I would be happy to try and implement the addition of the new attribute "allocated_lines".

[SchrodingersGat]

Thanks for making the change to the API annotation. However you have also added another display panel to the sales order page? It appers to be a duplicate of the existing "line items" panel?