Supplier integration

[matmair]

This PR:

• GenericWebTransaction model
• transitions WebhookMessage to GenericWebTransaction
• Adds WebConnection (including admin, API)
• Adds WebConnectionTransaction inheriting from GenericWebTransaction)
• Adds ConnectionSetting (including API, admin)
• Adds PluginSearch view (in the API) to search through connections and adds it to search
• Adds SupplierMixin
• Adds get_api_url method to PluginConfig model
• Adds plugin_connections tag

Open:

• tests for webconnections
• tests for search API
• API to add part from search result
• tests for part add API
• UI for adding part from search result

Before merge:

• Move OAuth checks to mixin
• Move requests middleware to mixin
• Move WebConnectionData to plugin namespace
• Move SearchRunResult to plugin namespace

Fixes parts of #3261

[wolflu05]

Note: This class needs some rework after merging master in (Ref: #4834 )

[matmair]

probably, a lot has changed in this area

[github-actions]

This PR seems stale. Please react to show this is still important.

[wolflu05]

I definitely want to have that feature, but currently the react refactor is in focus.

[github-actions]

This PR seems stale. Please react to show this is still important.

[matmair]

Still in the WIP pipeline

[SchrodingersGat]

@matmair I'm still very keen to see this implemented - do you have motivation on this still too? Does this in your mind require the react integration, or can we look at getting it merged in now?

[matmair]

I will move this to a plugin; it requires either the react integration or shipping the UI - which I will do with the plugin. Development velocity is also much easier to handle in a plugin.

[30350n]

How is that going to work then? Would this plugin basically enable the use of other supplier plugins? Or would it just be one big plugin supporting multiple suppliers?

Tbh I haven't really had time to look at this in depth yet, but I feel like it'd integrate well with what I've been working on in #5509 and the backend part should probably be in core ... buuut I really have no clue about the frontend requirements here. Could this maybe be divided into multiple smaller features/PRs?

Also, regarding actual supplier support: I've seen that you already have a WIP digikey plugin. I've been working on my own part importer script (basically a simplified/improved version of Ki-nTree, with proper support for nested categories). It's working quite well for my purposes, but I still feel like it shouldn't really be a script, but a plugin aswell, thus useable directly from the inventree interface. So I'd be interested in contributing that into core/your plugin aswell.

[matmair]

There will be a plugin that provides a basic UI and all that is required to handle the typical flows like search, data gathering, and creation of new parts/stock. I will not continue development with core as a target.

This plugin can be used as a target for vendor-specific APIs.

[nikolai2111]

Is there a better / recent setup guide than this #3791 (comment)?

In my current setup there is only one setting available and it's called "Supplier - The Supplier which acts as 'DigiKey'".

[matmair]

This PR is closed, development of this was shifted and none of the linked components are finished. I refactored basically the whole thing, some of the decisions made here were not scalable enough.

[30350n]

In my current setup there is only one setting available and it's called "Supplier - The Supplier which acts as 'DigiKey'".

That's from the supplier barcode plugins (introduced in #5509).

[nikolai2111]

Ah I see, I thought it was the same thing.
So there won't be a native DigiKey plugin?

Thanks for the info.