Well, if it is in fact an audit log, then you should never be able to undelete, because then your log can't be trusted. You should be able to clone a deleted record however. If you are just using your auditing log like a recycle bin, then please name it as such.
I work in the healthcare industry, and we are very strict about what is an audit log and what is not - if it isn't logged, it didn't happen. The fact that a delete happened on a certain date, and an 'undelete' happened on another date tells me what information was visible to users during that time period. By 'undeleting' from the log, you are essentially changing history (which we all should know is impossible). In any case, you can count this as a vote for not allowing undeletes by changing the is_active flag. Thanks, Derek Wilson On Wednesday, December 26, 2012 10:02:38 PM UTC-7, Mandar Vaze wrote: > > > On Wed, Dec 26, 2012 at 11:08 PM, Massimo Di Pierro > <[email protected]<javascript:> > > wrote: > >> there is a ticket about. I understand the problem but there is a logic >> problem. if is_active=False with versioning it means the record was >> deleted. So the record is ignored. It should not be visible at all except >> for auditing purposes. Now you are trying to bring it back to life >> (undelete it). It is not 100% obvious to me what the right behavior is. >> Granted that the right behavior is incorrect. Should one be allowed to set >> is_active=True or should one be forced to create a new record? >> > > Here is a use case : > > "Normal" user deletes a record, is_active is set to False. s/he and other > "normal" users can never *see* this record, obviously they can't even > attempt to undelete. For them the record is gone (they don't know whether > it was actually deleted from the DB or just marked as not active) > But for whatever reason, they want the record back, may be it was deleted > by mistake (They meant to delete other record, not this one ... blah blah > ... You know how users are :) ) So they report/complain to the admin about > it. > > "Admin" user doesn't use normal interface, s/he uses "appadmin" interface > and see the records as seen in the DB. S/he thinks, "Oh, the record isn't > gone, just marked as not active. This makes my life easier. I'll just set > "is_active" to True, click submit. Oh, I see "done" that means now record > is visible to "normal" user as well. My job is done" But guess what, > is_active is still False. "Normal" user still can't see the record. > > I understand that it is NOT obvious whether to allow undelete or user must > create new record. But that isn't my problem. > Problem is "done" flashed to the user. So "appadmin" user "thinks" that > this is allowed *and* assumes that is_active is now set to True, But it > is NOT. > > So if you decide that "undelete is NOT allowed" - Let user know that > clearly. "Done" usually indicates Success. > > If on the other hand, if you decide to "allow undelete" - well, then > is_active=True transaction needs to be committed to the DB before flashing > "done" > > -Mandar > > P.S: BTW, this isn't end-of-the-world scenario, I was able to set > "is_active=True" via mysql command prompt. But only because I rechecked the > record and realized that is_active is still False. > --
