BOM import: add field selection for item reference (ID/IPN/Name)

[TehDmitry]

#9248, #9382 and partly #7574
inspired by #2349

edit matmair:
Closes #9248
Closes #7574

[netlify]

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

Name	Link
🔨 Latest commit	e7d9867
🔍 Latest deploy log	https://app.netlify.com/projects/inventree-web-pui-preview/deploys/68beec5f5f495b00082d3d85
😎 Deploy Preview	https://deploy-preview-10268--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: 91 (🔴 down 4 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.

[SchrodingersGat]

@TehDmitry this is an interesting idea, but your approach is very much hard-wired for "part" import. The importer works for many different models, and so the approach should be generic too.

I would suggest that to make this generic, we add a list of possible "Import ID" fields to the underlying import model class. So, for the "Part" class, you might add:

class Part(...):
    
    def import_id_fields(self):
        """Return a list of potential ID fields for import."""
        return ['pk', 'IPN', 'name']
       

If this method is not specified, then the importer just uses the 'pk' field (as a default).

The import process then matches the provided field values, to the "names" of the fields (which are translated already, so we don't need to replicate that).

Then, the import system exposes the available import field types for any "foreign key relation" to the frontend.

I like the frontend implementation, that's a clean way of handling this.

Overall, this is a really nice enhancement - we just need to make it generic!

[codecov]

Codecov Report

❌ Patch coverage is 31.57895% with 26 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (a47a022) to head (e7d9867).
⚠️ Report is 178 commits behind head on master.

❌ Your patch check has failed because the patch coverage (17.64%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.
❌ Your project check has failed because the head coverage (89.55%) is below the target coverage (90.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10268      +/-   ##
==========================================
- Coverage   87.40%   86.19%   -1.22%     
==========================================
  Files        1266     1266              
  Lines       56455    57830    +1375     
  Branches     2061     2064       +3     
==========================================
+ Hits        49345    49847     +502     
- Misses       6603     7475     +872     
- Partials      507      508       +1     

Flag	Coverage Δ
backend	88.98% <42.85%> (-0.15%)	⬇️

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

Components	Coverage Δ
Backend Apps	89.55% <33.33%> (-2.12%)	⬇️
Backend General	93.64% <ø> (ø)
Frontend	70.06% <17.64%> (+<0.01%)	⬆️

🚀 New features to boost your workflow:

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

[SchrodingersGat]

Looks like you still have some hard-coded fields here - the "import_as" fields should not have to be called out by name.

[SchrodingersGat]

Nice, this is a simple way to specify the import-as options

[SchrodingersGat]

This should be ImporterImportAsSelect - it is not specific to importing parts, it should be generic across any type of import

[SchrodingersGat]

@TehDmitry have you had any chance to review this further?

[Badokas]

Any updates on this? We need this functionality, maybe I can help?