How to save objects when approval is needed to actually make changes?

Question

So I have an object graph, let's just say it's an order. You have the order class, line item class, tracking number class, payment class. You get the idea.

Now the business requirement is any user can change the order, but order changes must be approved by the manager. Until the manger approves nothing changes. Managers can change anything, at any time, without approval.

What are the best practices for dealing with situations like this? Saving the many (possible) different states of the order object and eventually approving or rejecting the changes.

i'm using C# and Nhibernate.

Thanks, Kyle.

Answer 1

I do not have any experience with nHibernate.

For a scenario like this, it is better left to database to store Order (state = ForManagerToApproveOrReject) and it can then be queried to see which Orders are waiting for approval/rejection (from manager's view)

A manager can then either approve/reject it. The inheritance mode of saving Order (ApprovedOrder, RejectedOrder) seems little odd.

Answer 2

I understand that part, the issue I'm having is figuring out how/where to save all the changes while the order is not approved. For instance, User A adds a payment, user B changes the address and User C adds a new line item.

until the manager approves the order stays as it was originally created (or retrieved from DB). Once manager is in the approval screen he/she can approve/reject each change. Changes are written to the original order and an audit is kept. User A changed xxx at yyy approved by zzz at aaa.

Answer 3

I would create a transaction table. It would have a record for each pending change. It would reference the order table.

So an order would get created but have a pending change; a record would be inserted into the orders table, with a status column of pending, and a record would be insterted into the OrderTransaction table.

For every change another record would get inserted into the OrderTransaction table.

I would also set up a RequestedChanges table with all the possible requested changes.

Answer 4

Similar to Sam WIlliamson's idea about a transaction table, I would use a temporary table.

Changes made by someone who is not a manager, go to new Order objects in the temp table. The manager will have an interface to review these orders pending approval, and the system will have all the changes saved already, but outside of the standard position.

This might be an issue for the user's interface as well, they will have to see both the official version of an order and the pending-revision version side by side to make sense of the state of the object.

Anyway I think your best bet is to store the objects as normal, but in a separate table from the official records, pending review by the manager. This temp table should never grow very large, as it represents the backlog of approvals the manager has to get to.

Answer 5

a simple solution is to just make another order that is a copy of the original with the changes applied, the status set to PendingApproval, and an auto-increment VersionNumber. change the table's primary key to include ApprovalDate. Then the current, approved order is always the one with the most recent approval date.

Answer 6

What you are describing is a workflow, it actually sounds to me like a good candidate for Windows Workflow Foundation. If your workflow is business critical I would be inclined to separate it out from your database logic, WWF will allow you to do this.

Answer 7

If orders are not complete until approved you may want to have a pending orders, and completed orders table structure. Pending orders might just be serialized objects and only write it out to order, order lines etc once approved.

If you allow changing orders after approval it become more complicated, you may also need to take into account post approval steps, payment received, picking, packing, shipping etc.

There are lots of ways to do this type of thing, how you do it will really depend on what the real business requirements are. i.e. you say managers can change orders at any time, but should they really be allowed to change a shipped order?

Answer 8

thanks for all the answers. The actual business use case is not creating orders, but if I tried to explain the actual business I'd have to write a couple paragraphs. The bottom line is managers need to moderate changes on a deeply nested object graph, before they "go live."

I like the transaction table idea.

I also like saving two versions of the "order," one with changes, one without.

I guess I'll have to dive into both and see what happens.