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.
Should a persisted and 'finished' by state transaction be editable to any user
business rules
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.