Custom states

[matmair]

Continuation of #4857. This PR will add database interactions for states - enabling custom states.

• enables setting default states for stock [FR] Make default stock status settable through settings page #4589
• adds the possibility to define custom states (decoupled from business logic states) Custom Stock Status #4289

[netlify]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	0817152
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/65a51da88c7f8b00087d2cd5

[gunstr]

@SchrodingersGat I'm sorry to see this PR moved into horizon. I use the stock status a lot. There is nothing wrong with the default tags. However I also flag other reasons such as consumables, lab items, borrowed and a few more. I use this to know the condition for each stock item and also as a filter criteria for stock valuation - I guess spot on with the intention of the Stock Status.

As a compromize I modify the core code for each upgrade so the tags and business logic reflects the most important conditions I use and thus sacrifice the default tags. Works well for me, but obvioulsy have some drawbacks that would be resolved if customized Stock Status were implemented.

We discussed the same also in #4289 and I then said I will give it a try to develop but have realized that the complexity to implement is far beyond my coding skills. When I see what @matmair has done already in this PR that becomes even more clear.

I so greatful for all your work on InvenTree and realize you have tons of requests and need to prioritize. But I just want to highligt that for me this would be a really nice feature.

[wolflu05]

@matmair I'm interested on what the current status of this PR is, it seems like it has no file changes? Did you started implementing this already and have some unpublished code? And do you plan to continue this in some time?

[matmair]

I have a POC that was developed in tandem with #4857, most of the generalised stuff was merged into #4857 eventually and the rest is already used (with a few ineficientes / edge cases TBH) in my deployed instances.
Missing is a generalised model that implements the link between a custom display state (maybe with plugin locking) and core models. Business logic would not be touched by that but there are some performance things to consider/test (one could either add a direct lookup field to every model using states which would safe us a database query (in a cached scenario) or for a more plugin friendly implementation via content types). Most "magic" needed to tap into the business logic has already been merged into master: #6017, that test cases around that probably need adaption.

That is a huge change in the possible depth of (busniess) logic-change plugins can make. So I wanted to wait for #5861, #5578, #2493 to ensure we are not stuck with either a lot of questions about the different models or broken plugins that messed up users instances. That is an organisational thing, not a technical blocker. This PR could certainly be finished without adressing these project-level short-comings.
If you are intrested in developing this I can expand this discussion with more technical minutiae and QoL things that should be considered.

[wolflu05]

Ok, thanks for the detailed explanation. But unfortunately I have no time developing this. I really appreciate your work.

[matmair]

At some point, I want to tackle this but it is low on the ToDo. I will close this PR, it suggests that I am active on this front, which I am not.