I have to prevent a user from approving a change that she made. I have a way to get the history for the users who changed the item. For a simple case I can just check who was the last person that modified the item and prevent her from approving it. However, for cases such as below, what's the best way to implent it?
User 1 saves, User 2 approves and then unapproves, User 1 now should not be able to approve
User 1 saves, User 2 approves and then unapproves, User 3 approves and then unapproves, User 1 now should not be able to approve
Dalia Sultana wrote:Having said that, I am thinking we can look for a consecutive approval & unapproval pair by a particular user and consider it void.
That is a complicated way of doing it. I have attached a little state diagram that I think describes what you are doing. This are the states and the transitions of an item. I would suggest that you always store all transitions of an item so that when you do save on an item, you store who and when. Then you can always ask "who save it" (public User getSavedBy()) and also the state. The isApproved() should look at the last approval state. When you set approved (public boolean setApproved(User user, boolean a(==true))) you store that line in the data storage. Then you have two ways of doing the "un-approval". Either you remove the approval state (that is how I drawn in the state diagram) or you just add a new state "un-approved" that can only go to edit or approved states.
There could be a state when user Ad saves an Item, user FP approved it and user Prostetnic Vogon Jeltz unappoves it...
Dalia Sultana wrote:No, I only have history about approval and unapproval. Basically when an approved entity is changed, it's put in an unapproved state.
So, from what you're saying, there are three types of change: an approval, an unapproval, and a modification, with the latter resulting in an 'unapproval'.
Have I got it right?
If so, one approach might be a stack, maybe something like this (in my bad pseudo-code):but I'm sure there's a raft of other possibilities too.