How do you deal with delete function in websites.

[M.Zeb Khan]

Hi,

Me and my other web dev mate were just talking about that when working on websites for clients the delete function should not delete the entry straightaway. Like if a client is working in his admin area of the CMS and by mistake he delete an entry or content from the admin area and give you a call that "oh I just deleted this by mistake", even though if you javascript confirm() it still, if he deletes not by mistake, still if he wants the entry or the content back.

So we came to an end that we should make our CMS to not delete things straightaway, but would use an extra field in the table called "trash", so if the trash value is 0 show the content else hide it, and when the client needs it back make it 0 again.

What are your ideas on this?

[cdsanchez]

Hi,

Me and my other web dev mate were just talking about that when working on websites for clients the delete function should not delete the entry straightaway. Like if a client is working in his admin area of the CMS and by mistake he delete an entry or content from the admin area and give you a call that "oh I just deleted this by mistake", even though if you javascript confirm() it still, if he deletes not by mistake, still if he wants the entry or the content back.

So we came to an end that we should make our CMS to not delete things straightaway, but would use an extra field in the table called "trash", so if the trash value is 0 show the content else hide it, and when the client needs it back make it 0 again.

What are your ideas on this?

Or you could give them the option of disabling the content but still keep it in the database for if they want to use it in the future, or deleting it permanently. You could just add another field to entry in the database ("enabled" - 1 or 0)

This would be more convenient and easier to integrate IMO.

[M.Zeb Khan]

Or you could give them the option of disabling the content but still keep it in the database for if they want to use it in the future, or deleting it permanently. You could just add another field to entry in the database ("enabled" - 1 or 0)

This would be more convenient and easier to integrate IMO.

That's a cool idea now, lets see what other says

[waji]

Hi,

"oh I just deleted this by mistake", even though if you javascript confirm() it still, if he deletes not by mistake, still if he wants the entry or the content back.

tell them that you have to pay for your mistakes, and the re-entry will cost you this much $$ lolz, anyhow the idea of disabling the content is pretty cool rather deleting forever.

[SJH]

In my CMS when a user deletes an entry, it does exactly as you suggested in your post, it flags it as "deleted" which moves it to the recycle bin. There's also the option to have the recycle bin automatically empty after 30 days.

The "disabled" attribute in my CMS is additional to this "deleted" flag, the difference being that the entry will stay in the database indefinitely, and it will still appear in the list with all the other entries rather than sitting in the recycle bin.

[graedus_dave]

SJH, how do you track the length of time it has been deleted?

I was just implementing a similar tool in an application the other day. I initially had a 'deleted' flag, but then I thought I should make deleted a timestamp -- if it is 00-00-0000 then the record is active; otherwise it shows the date it was deleted.

What do you think of that?

[ghuytro]

A few things, some of which has already been mentioned:

1) Instead of deleting either

a) Have a column that sets the record's "is deleted / expired etc." status
b) Move the data to a {tablename}_deleted table. This could be useful if it's a table with a lot of rows that is heavily accessed / indexed etc by your application. No sense having expired/old/deleted data in a table.

2) Keep an audit trail of the delete action. Store in the db:

* user id of the user who "deleted" the content
* date content was "deleted"

Sometimes you need to find out "Who in the hell deleted such and such!?"

3) From a UI delete confirmation POV you could do either or (you should probably do both in case JavaScript is disabled):

a) I find a JavaScript confirm() to be useful. Catch the form submit:

if ( confirm( "Do you want to delete this?" ) )
{
   // Submit form
} 

b) In case JavaScript has been disabled, send the the delete to an intermediate confirmation page similar to the above. You could have an <a> link or a button that submits the delete confirmation.

[Ken Sharpe]

The "deleted" flag is what is commonly used in large corps, but most often it's called "active."

I'm with the guys at humanized -- you should never ask for confirmation, just show an unobtrusive message that says "Widget Deleted. Click here to Undo." The recycle bin is a great idea.