Symphony.

I'm administrating the website of a degree course at the university I'm working at. There are other users (students and stuff) who are adding news to a section. One of those deleted a few entries - which he shouldn't but - well - it happened.

Now I have a question: Should delete really delete for normal Symphony users?
There isn't any backup system in Symphony itself - how do you handle this problem in real-life environments?

We usually add a "Deleted", "Enabled" or "Published" checkbox to entries like these (depending on context). On some sites we have editors moderating submissions, so add a Select box with Pending/Declined/Approved and filter appropriately in the DS.

This was out of necessity than foresight, since we've built an interface to edit certain sections through front-end pages; and Events are not able to delete entries. But a front end event can update a select box :)

Well, okay, we're doing quite the same: We have a checkbox saying publish?. But it seems to be hard for some people to remember to simply uncheck this box when they see a delete button which seems to do "the right thing" (eliminating the entry from the site).

My problem is really a workflow problem: How to deal with the delete button, which really deletes, has no undo option and is quite present in the admin interface? Is there a simple way to add and restore option for administrators?

@Nils: If you have the right to edit, you should have the right to delete as well. Once you break this logic apart, you will soon find yourself in the hell of "workflow management solutions". Every day will bring new issues. Some authors will be allowed to add text, but not to delete text. Or delete images only? Add videos, but no video descriptions? Change entry sorting only, but not the content? There is no end to this. So I think it will be better to teach your authors that "delete means delete".

Up to now I was lucky not to experience your problem. But I do automated database backups (plus filesystem backups) once a day. So in case something goes terribly wrong, I can restore the site. Of course, since content might have been added since the latest database backup, restoring a few entries might be a manual process (rather than a simple complete rollback).

The above is no solution to your real-world problem. Maybe you should simply remove the delete button using an extension or hacking the core.

(Nevertheless I admit that I still miss the author access restrictions of Symphony 1.7... And I am still hoping for advanced access control in Symphony 2.)

If you have the right to edit, you should have the right to delete as well.

You're totally right. I was thinking about something in the background - maybe like a table sym_abbandoned in the database where deleted entries are moved to. Something like the trash on the computer, where things are moved to, but not deleted instantly.

So I think it will be better to teach your authors that "delete means delete".

Well, that's right, too. I tried to - but we are using so many different administrating systems here, that people get confused with the things they learned ... and start making mistakes.

(Ah, and yes, I do have copies of the database and of all files, but I thought it would be a good idea to talk about the problem and if there are possible improvements to the interface.)

There could be a system-wide "deleted" flag on every entry perhaps. This would require a modification to the entries table. Since Symphony does not re-use IDs when entries have been deleted anyway, I wonder how much it would take to build this functionality in.

I am not a big fan of the "Deleted is not really deleted" idea, even if to the user it appears deleted. Vanilla forum did that and it always bothered me since it was unintuitive to go and clean out the faux deleted entries. I do, however, like the the idea of an Extension that listens to the deletion of entries and makes a backup copy to a table it controls. That way the interface is separate and potentially give us much more control.

I would imagine this extension could listen to sections of choice and allow restoration of previously deleted entries. And if you want to get really fancy, perhaps there could be per-user rules, like "user A, B and D will have entries backed up, but user C does not".