I came from a background where I taught that when a transaction reached some state (FINISHED, PRINTED, etc) it should no longer be opened for modification even to admin users.
But here I am, fixing their human-input error barbarically by deleting a row in database and/or changing the current item’s state to it’s previous one.
At some point they even make a mistake in inputting a transaction date, and just realized it somewhere later.
And it’s really annoying.
Should a software, especially an enterprise one, gives a user all the freedom they requested?
If so, what good does a transaction state for?
Update :
Here, by transaction I mean a Transaction object which usually consisted a reference to Master object and it’s own attributes, not database transaction.
Your users obviously need a feature (changing or removing of an item after it has reached a certain transaction state) which your application doesn’t provide. It seems like when designing the application you thought that there would never be a reason to do so, but the task you are currently performing proves that there is. Otherwise you wouldn’t have to do it.
Nobody is perfect. Input errors are human, as is not noticing them until it is too late. Every business process and the software system which represents it must keep that in mind.
When revision requirements dictate that a document must not be invisibly changed after a certain point in the business process was reached, there should be a way to make the correction transparently. This can happen by using a visible change history of an item or by setting its status to “VOID” or “CANCELED” and creating a new item. The latter also allows to define a proper process for these situations.
Example: When the status of an invoice changes from “PRINTED” to “CANCELED”, automatically print an apology letter telling the customer to ignore the previous invoice.
3
By transaction state, I don’t know what you mean clearly. Maybe you should expand a little bit. But I think a kind of misunderstanding has happened here.
A transaction is by definition an ACID operation. In brief, a transaction should:
- Either be performed completely, or not at all. Never anything in-between.
- Not violate the consistency rules (like constraints) of data
- Be performed in an isolated space from other transactions (according to transaction isolation level specified)
- Be durable, that is, continue to exist and not be temporary
Now, after a transaction has happened, still anybody with enough privileges can access the database, and change it just like any other normal data.
In other words, what exist before and after a transaction, is pure data. You can manipulate it just like any other data. Transactionally-inserted data is nothing special. It’s not that you can’t or you shouldn’t change it manually.
1