[RFC|Accepted] Soft Delete

[imkingdavid]

When combined with post revisions, should a soft delete and/or restore be considered a revision (for auditing purposes)?

If so, I'd hate to store an entire revision just to keep track of a post being deleted. If we choose to do this, we should add another column on the revisions table to differentiate between the type of revision. For instance, editing a post would be handled differently than soft deleting or undeleting (restoring) a post, but we could keep track of each of those types (or other types) in the chronological list of revisions. Of course, only the revisions for when a post has been edited will be able to be compared and such. Personally, I'm not sure if I'd like to do that, or if we should just keep track of it in the Moderator Logs.

[Pony99CA]

When combined with post revisions, should a soft delete and/or restore be considered a revision (for auditing purposes)?

If so, I'd hate to store an entire revision just to keep track of a post being deleted. If we choose to do this, we should add another column on the revisions table to differentiate between the type of revision. For instance, editing a post would be handled differently than soft deleting or undeleting (restoring) a post, but we could keep track of each of those types (or other types) in the chronological list of revisions. Of course, only the revisions for when a post has been edited will be able to be compared and such.

Yeah, I'm not sure if it's worth the effort, but I wanted to bring it up as a concern.

Personally, I'm not sure if I'd like to do that, or if we should just keep track of it in the Moderator Logs.

That's fine for normal posts, but for Wiki posts, I presume that anybody would be able to soft delete them, and that might be something you'd want everybody in the topic to see (if only to report a troublemaker trying to delete your post).

Steve

[brunoais]

If a user soft deletes a post, and a moderator restores it (perhaps because the deletion broke the flow of the topic), should the user be blocked from soft deleting it again or is appropriate action for the moderator to restore and then lock the post (because the user could still edit it)?

Allowing a user to edit a post is as painful as allowing the user to edit the post. When editing the post that was restored, a user can (and probably will) just clear the whole text and replace it with some dummy text mentioning that the post is deleted. For the usefulness of the topic, that is useless.
BTW, [offtopic]if the user knows about the restoration system and the post is restored, he'll (almost definitely) try to ruin it again.[/offtopic]
That's what my experience as a forum moderator says.

[imkingdavid]

If a user soft deletes a post, and a moderator restores it (perhaps because the deletion broke the flow of the topic), should the user be blocked from soft deleting it again or is appropriate action for the moderator to restore and then lock the post (because the user could still edit it)?

Allowing a user to edit a post is as painful as allowing the user to edit the post. When editing the post that was restored, a user can (and probably will) just clear the whole text and replace it with some dummy text mentioning that the post is deleted. For the usefulness of the topic, that is useless.
BTW, [offtopic]if the user knows about the restoration system and the post is restored, he'll (almost definitely) try to ruin it again.[/offtopic]
That's what my experience as a forum moderator says.

So then should "Edit Lock" prevent soft-deletion as well as editing? That would be a solution to both issues.

[canonknipser]

@brunoais: the case of delete-content-by-edit should be solved by post revision tracking.

@imkingdavid: yes, of course - deleting is also a kind if edit - and soft-delete also should respect the edit time interval set in acp.

[brunoais]

If a user soft deletes a post, and a moderator restores it (perhaps because the deletion broke the flow of the topic), should the user be blocked from soft deleting it again or is appropriate action for the moderator to restore and then lock the post (because the user could still edit it)?

Allowing a user to edit a post is as painful as allowing the user to edit the post. When editing the post that was restored, a user can (and probably will) just clear the whole text and replace it with some dummy text mentioning that the post is deleted. For the usefulness of the topic, that is useless.
BTW, [offtopic]if the user knows about the restoration system and the post is restored, he'll (almost definitely) try to ruin it again.[/offtopic]
That's what my experience as a forum moderator says.

So then should "Edit Lock" prevent soft-deletion as well as editing? That would be a solution to both issues.

Yeah... that seems to be the best option. not some thing that acts as: If the moderator did it, the user cannot go back from it.
E.g. user locking the topic vs moderator locking the topic
Just give the moderator the undelete + lock option.

[EXreaction]

Instead of adding new permissions for soft deletion, permissions should be added for permanent deletion, and the current delete permission would become the soft delete permission setting. Permission to permanently delete posts or topics should be given out less often after soft deletion is available.

Whats the difference between what i was saying? Doesnt really matter which one is which, if the setting is copied anyway.

I dont think that anyone should have the ability to hard delete, it destroys history that should be kept if the user is not removed. If the current delete permissions are used for soft delete and nobody is given hard deletion permission, the administrators will have to decide themselves who can hard delete posts/topics.

When a user soft deletes their own post, they should be able to see it, plus anyone with moderator level soft deletion permission.

Why should users be able to see posts they just deleted, and don't have permissions to restore? I really dont see a point in this, so the next three questions are obsoleted.

I'm not sure where you got that from at all. If a user soft deletes a post they should be able to see it.

If someone has the ability to see a soft deleted post, they should be able to restore it (after all, they could just quote and repost it), there does not need to be a separate permission for that.

So restoring would be part of m_softdelete rather then m_approve? This will increase the complexity of queries and so slowing down search/feed and other get topics of all forums functions

Again, approving posts is entirely different than restoring ones that were deleted, the two should be completely independent permission wise.

Soft deleted posts should not show up in a moderation queue....

Where else would a moderator have the ability to restore posts/topics in the MCP then?!

They would be shown inline to people with the ability to restore them, just with a notice they've been deleted. They don't need a place to restore posts within the MCP, I don't see how that would benefit anyone.

if the post is locked by a moderator, is the user able to restore or soft delete?

1. users should never be able to restore posts
2. if a post is locked it can not be modified by the user (irrelevant because of 1)

When was it decided that users should never be able to restore posts?

[drathbun]

Regarding soft delete + post revision interaction: My opinion is that the two are completely separate. A soft delete is not a revision. If a post is soft deleted, then all revisions are processed in the same way as the current post version. That is, if the soft delete becomes a hard-delete at some point, then all revisions are removed. If the soft delete is undeleted, then the revision history is still present. But neither of those actions trigger a new post in the revision history as they are non-edit actions. Just my two cents.

[brunoais]

^
That really does makes sense.

[nickvergessen]

I'm currently still trying to figure out, how the best structure for this would be.

The idea of EXreactions plan is quite complex, because when m_approve and m_restore are seperated, there are multiple kinds of hidden topics. The following graph shows the topic status as a result of the included posts. (Moderative soft delete hole topic is not even implemented yet):

(A Box is ment to be a topic, the types in it, are the different types of posts that are in the topic)

I don't really like this result, as it is really hard to understand and follow. Also, what should happen in case 6. (Unapproved and Softdeleted)? Who should be able to see it?

However with the plan I published on 31th August, m_approve and m_restore are merged into one permission and f_restore does not exist, the Graph is quite simple to follow:

Therefor I somewhat would still prefer the second route.