InvenTree
InvenTree copied to clipboard
inventree
Custom Stock Status
Please verify that this feature request has NOT been suggested before.
- [X] I checked and didn't find a similar feature request
Problem statement
It would be more user friendly if you were able to customize your stock status options. As an example I would like to use a status like "tested", "in production" or similar ones. The current status options are not enough for me to use them properly.
Suggested solution
Enable the option to create custom status options in the admin menu.
Describe alternatives you've considered
Extending the amount of predefined status options.
Examples of other systems
No response
Do you want to develop this?
- [ ] I want to develop this.
Upvote & Fund
- We're using Polar.sh so you can upvote and help fund this issue.
- We receive the funding once the issue is completed & confirmed by you.
- Thank you in advance for helping prioritize & fund our backlog.
Hi there @Fluxus00! The values for stock status are hard-coded and intertwined with the wider StatusCode system at the moment. It would be possible - from my POV - to decouple shown names from business logic by creating linked categories in the database. Those could have customizable names. There are some things to watch out for regarding API integration, migration path for existing users, translating and object lifecycle. It seems to be possible with a bit of work.
On my personal priority list, this is very low but if someone is interested I think we would be willing to give pointers, review and merge into core. If this is tackled, I would encourage the person doing so to migrate all StatusCode components as the additional work is probably comparatively small if you did it for one of the inheritors.
When I migrated to InvenTree a year back I had similar need as @Fluxus00 primarily because I have different reasons than what is hard coded to why stock should be treated as available and more important what should be included in overall inventory valuation and not. My first solution was to anyway use the status codes but with a note on my desk to translate between what I saw on the screen and the actual status.
This was obviously error prone why I now in my local installation have changed the hard coded values in the StockStatus class. It works well for my use cases, only little drawback is that the status codes are obviously not propagated the app.
I have seen FR's for the same being raised before why there is probably more people being interested. But as @matmair mention a proper solution comes with so much more and unfortunately I have not yet managed to build enough competence in the architecture to feel comfortable to volunteer for a full implementation. Maybe later this year when I have retired from my full time work...
Just a thought - given the complexity of the current status code, would a "tag" field with no business logic impact and with configurable values be an option?
@gunstr ping me or @SchrodingersGat here if you want some pointers how this could be done. There are many ways to achieve the requested functionality. I will not provide a recommended way right now as the code base is moving somewhat fast and the references/names could change till you take a stab at it.
I think this makes sense to implement "fully" - make all stock status codes customizable by the user. This will give us more flexibility down the line too.
Thank you all for your replies! It seems like I was underestimating the amount of work my request would require.
@gunstr Actually I am very interested into your solution. At the moment I am not using the app, so this would not be a problem.
May be you would be so kind to share which values/ lines/ variables you changed? Until the official release it would definitely help me, and maybe also other users.
I would caution against forking and changing core code permanently. It will make regular updateing - which is very important in terms of security - a lot harder.
@matmair I understand and also I was already expecting that this would cause troubles. That is why I want at first to know the required steps, but still thank you for your advise!
I can only agree, this is not really a nice or recommended way to go although it has worked well for me for at least half a year now. I have my changes well documented and use a couple of local git branches to re-apply the changes and handle potential conflicts during upgrades, but it for sure comes with a risk.
@Fluxus00, I do not really want to post any "non approved" code changes and what I have done is also very specific for my use case. If you cannot figure out by yourself what you need to do in the class I pointed to I would also advice against to change any code at all. And if you anyway try it out - make sure you know exactly how to handle future upgrades!
I hope to be able to come back with a PR for the full implementation later this year - if not anyone else is faster.
There were a couple of issues related to this one in the past: #1386, #1301.
@Fluxus00 there has been some more interest in this feature - would your company be willing to chip in some sponsorship to help bring some attention to this issue?
@bmalatest we use polar.sh for fundig, feel free to contribute what you can/want there. It offers both immediately funding and after the feature was merged
Working on this now with main implemntations:
- end-user custom states - those are basically just an additional field that can be defined during run time and are always linked to one specific logical state
- registry based states - those can be defined in Python code and can be assigned to state groups
In this order
I have a working backend implementation but I think I will need till 0.16.0 to get testing and UI done.
I joined this community recently - and after some Inventree testing, I also discovered the need for "special" locations that would not count towards the overall store . Now we solve this by marking the item as "LOST" but this means 2 steps when moving between locations : 1st step move, 2nd step mark as LOST ....:-) I'll try to "throw" funds into polar.sh ( unfortunately it's not only up to me:-) )
I have a working backend implementation but I think I will need till 0.16.0 to get testing and UI done.
@matmair May I ask what the current status is with this? Do you think this will make it into 0.16? Is there anything you need help with?
I think I can file a PR for this tonight; I am still searching for some inefficient lookups but that would be solveable
Thank you @matmair for contributing to close this issue! ⭐
The rewards from this issue, totaling $100, has been shared with you.
What now?
- Create a Polar account
- See incoming rewards & setup Stripe to receive them
- Get payouts as backers finalize their payments
If you already have a Polar account setup, you don't need to do anything.