@cpattersonic2 invenTree is not a purchasing software. We do not handle any form of accounting so you will still need a solution for that even if this FR is implemented.
I would not hold my breath for this to be implemented in core as there are multiple things that would need to be adjusted and the core team is small.
This should work well as a plugin though.

@cpattersonic2 I can see the value here, although it would not be for everyone. if it was to be implemented as a first class feature rather than a plugin it would need (at minimum):

• Settings which control whether PO's require approval (default OFF)
• Add model fields to purchase order to indicate who approved (and when)
• User interface additions (i.e. display approval, buttons to approve, etc)
• Update API to allow approval / revoke approval of order
• Generation of notifications based on approval
• Unit testing

So this is a fair amount of work. If it is something you are keen to pursue, and don't want to develop yourself, you can reach out to us to sponsor development of this feature. Otherwise it will probably sit on the pile for some time (there's a lot of outstanding stuff).

@cpattersonic2 for such requests please send an email to support (at) inventree (dot) org

@SchrodingersGat If this is implemented I would suggest to directly build it as a new app so that aprovals are first-class citizens (at first probably just with API endpoints). That gives us the option to:

1. extend them with plugin mixin
2. use metadata from the start (app plugins)
3. build multi-stage approvals
4. build ACLs based on approver
5. use approvals for all orders

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

Not stale

@SchrodingersGat thank you for bumping this. End of the year contracts had us busy, and this had fallen off the task list. I'll try to get the PO out this week for the feature add. Awesome 0.9 stable release!

@SchrodingersGat I think the accountants went through to pay the sponsorship. Please let me know if you need any other information from us. Thanks for the awesome work on Invetree. Kicad 7.0 with database integration will be an interesting choice on whether to hitch Inventree's wagon to Kicad so to speak.

@cpattersonic2 we are already discussing and working on KiCad 7.0 integration - see #4133. From what I have now it seems like the user will have to do a bit of setup to get it running (mapping parameters in InvenTree to KiCad footprint fields).

Regarding this FR: Do you have any other requirements/wishes you would like to add? We already need to add a fair bit of models and business logic so it might be easier to add it from the beginning / consider it from the start.

@SchrodingersGat I own a code base that has a lot of the logic and models required for this already. It might be too complex though as it includes:

• dynamic approval requirements (min number of approvers, max number of deniers, quorum, user attribute-based rules)
• nearly unlimited number of approvers per case
• revoke removal
• time limits on cases
  Would that be overkill or should I drop the code in a PR? I will need to clean the code of some references and update it to Django 3 so asking before I invest time.

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

Not stale

There seems to be no interest in this feature, I will shift it to a private plugin

@matmair

I am at a small company who is also interested in this approval feature. Is there somewhere I can find the "private plugin" you mentioned? Should I try it out straight from #5095 ?

Let me know your recommended approach here

The PR in its public state is 2 months old and not functioning I dought it will be helpful without deep knolwedge of the code base.
I have shifted development of this into a private plugin registry that is only available to select communit members for beta testing, I am not searching for testers right now.

Fair enough... I've been tasked to solve this problem for our needs regardless. In an earlier message, you said approvals may have the following features

• dynamic approval requirements (min number of approvers, max number of deniers, quorum, user attribute-based rules)
• nearly unlimited number of approvers per case
• revoke removal

This sounds exactly like what we would need. Is this something that I should be holding my breath for, or should I start exploring other custom options?

I will note, after talking with some higher-ups we could potentially sponsor this work. I've had funding allocated to me to solve this, but an officially supported way of doing it would be our preference if possible.

I have no plans to upstream my code and my current developments in this regard only run on a custom fork that is optimized for my deployment scenarios.
Maybe mail the maintainer ([email protected]) with what exactly you need and he might be able to help you. You can CC me if you want ([email protected]).

I also work at a small company and have been keeping an eye on this feature for a while. Will this be re-added to the roadmap at all?

In order to migrate our ancient order system to using InvenTree PO's, I was banking a bit on this.
I'm happy to take over implementing this, at least as an initial MVP.

What would be people's minimum requirements for such an approval stage for orders?

A simple MVP could include the following:

1. User permission that allows a user blanket rights to approve anything
2. Tie situational approvers to project codes, so approval will be requested by the person connected to the order's project code

For an MVP, I'd rather avoid approval councils, majority votes etc. That could be added down the line.

In order to migrate our ancient order system to using InvenTree PO's, I was banking a bit on this. I'm happy to take over implementing this, at least as an initial MVP.

What would be people's minimum requirements for such an approval stage for orders?

A simple MVP could include the following:

1. User permission that allows a user blanket rights to approve anything
2. Tie situational approvers to project codes, so approval will be requested by the person connected to the order's project code

For an MVP, I'd rather avoid approval councils, majority votes etc. That could be added down the line.

Those functions would be ideal for us!

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

Not stale

My (closed source, plugin available) plugin for this is currently in beta and should receive a major update in the next few days now that #5753 is adressed;
install instructions, beta docs.

My roadmap to 1.0 was published a few days ago https://polar.sh/invenhost/posts/plans-for-2024-02 and rough docs are available here, feel free to raise questions or request features in the main plugin repo.

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

Not stale

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

Not stale