inventree / InvenTree

Open Source Inventory Management System
https://docs.inventree.org
MIT License
4.32k stars 781 forks source link

Custom Stock Status #4289

Closed Fluxus00 closed 2 months ago

Fluxus00 commented 1 year ago

Please verify that this feature request has NOT been suggested before.

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?

Upvote & Fund

Fund with Polar

matmair commented 1 year ago

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.

gunstr commented 1 year ago

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?

matmair commented 1 year ago

@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.

SchrodingersGat commented 1 year ago

Ref: https://github.com/inventree/InvenTree/issues/4253

SchrodingersGat commented 1 year ago

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.

Fluxus00 commented 1 year ago

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.

matmair commented 1 year ago

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.

Fluxus00 commented 1 year ago

@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!

gunstr commented 1 year ago

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.

sintech commented 1 year ago

There were a couple of issues related to this one in the past: #1386, #1301.

SchrodingersGat commented 9 months ago

@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 commented 7 months ago

We would be happy to help fund this feature

matmair commented 7 months ago

@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

matmair commented 7 months ago

Working on this now with main implemntations:

In this order

matmair commented 6 months ago

I have a working backend implementation but I think I will need till 0.16.0 to get testing and UI done.

czkapitan2 commented 5 months ago

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:-) )

wolflu05 commented 4 months ago

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?

matmair commented 3 months ago

I think I can file a PR for this tonight; I am still searching for some inefficient lookups but that would be solveable

SchrodingersGat commented 2 months ago

Thank you @matmair for contributing to close this issue! ⭐

The rewards from this issue, totaling $100, has been shared with you.

What now?

  1. Create a Polar account
  2. See incoming rewards & setup Stripe to receive them
  3. Get payouts as backers finalize their payments

If you already have a Polar account setup, you don't need to do anything.