Parameters for stock items

[lifeisafractal]

With the new generic parameter system introduced in 1.2, it looks like stock items could have parameters added pretty easily. I have a few use cases where I'd like to be able to pin some internal meta data to stock items. Regardless of my use case, I could see having the ability to attach user-defined meta data via parameters to stock items as useful and consistent with the new generic parameters concept.

For scope of effort, I think this would entail adding the InvenTree.models.InvenTreeParameterMixin to the StockItem model in the backend (not sure there is much else to do; the generic param system looks well thought out). On the front end (disclaimer: I have little front end experience) I'm guessing it should largely be a "copy-paste" to add the param UI to stock item, and maybe some tweaks in the admin center around the parameter template management (maybe this comes for free?).

A couple questions

1. Is this feature a good candidate for inclusion?
2. Is my rough assessment of the dev scope above more or less correct?

I'd consider taking a stab at a PR if the feature is in line with the project.

[matmair]

I am not sure using the "normal" mechanism as exposed by the mixin is correct for StockItem. This would lead to the potential for having differing parameter templates available on stock items of the same part.
IMO parameter templates for stock items should be defined on the part / part category level and should be inherited by stock items.

[lifeisafractal]

Thanks for the context. I think I understand what you're saying. I also think we have two distinct use models in mind, which I believe could co-exist in practice.

My understanding of your use case:
You propose parameter templates for stock items to be defined at the part or part category level and inherited by stock items of that part. This keeps parameters consistent across all stock items of the same part. E.g. if a resistor has a "measured resistance" parameter, all stock items of that resistor share that template (or also possibly inherited from a part group like "Resistors"). This model makes sense and aligns well with how part parameters already work in Inventree.

My use case:
I want to attach metadata to stock items as physical instances, uniformly across all items regardless of part association. This is essentially extending the StockItem model without core Inventree changes (the core use case for user parameters). My specific use case is adding an "Expense Status" parameter to mark items as expensed or capitalized. I know that's exactly the ERP territory Inventree is intentionally staying out of as a core feature, which is precisely why it belongs in a user-defined parameter. There are other reasonable cases too: inspection status, calibration dates, storage restrictions (ESD sensitive, refrigeration required, etc), and so on. These might not apply to most users, but that's why generic params fit well: let users solve their own edge cases.

Can these co-exist?
I think these two use cases can co-exist without much conflict. The part/category-level inherited parameters you described and globally-defined stock item parameters serve different purposes and don't obviously step on each other. I think the backend/data handling is straight forward, and the nuance is in how the UI and template management would need to clearly distinguish between the two, but that feels solvable.

My immediate need is the globally-defined stock item parameter case. Before I dig further into implementation, I want to gauge whether this is something the project would consider accepting a PR for. Happy to discuss further.

[matmair]

I think your use case misunderstands what parameters are for and how they were designed. This sounds like you should just use metadata in a plugin you make for your use case.

[lifeisafractal]

You're right for my expensing use case. That sounds like a prime candidate for metadata with a custom plugin. Thanks bringing that to my attention.

Separate from that, I still feel like there are plenty of use cases for StockItems to have generic parameter support. Some more tangible examples I can think of are:

• Manufacturer lot information
• Date code
• Condition grade (New, refurbished)
• Country of origin
• Firmware version
• Die revision (when vendors don't change the part number)
• etc.

In #10699 it looks like several models got the generic params treatment that didn't have any parameter support prior (Order, Company, Build). Having a way for adding simple UI accessible custom data like the above for StockItem still makes sense to me and it feels like it got overlooked in the original PR. I searched the comments in the PR and associated issues and saw no mention of Stock at all. Is there an explicit reason it was skipped in the PR?

[woju]

I'd like to second this proposal. My use case would be to track MAC addresses, IMEI numbers and possibly default credentials, which are associated with particular S/N, not P/N, and print all of them on a label.

Example of a product that has two different labels, with and without secrets (inside and outside of the packaging): https://wiki.teltonika-networks.com/view/RUT200_Product_Labels

[SchrodingersGat]

Ref: #11459