[RFC|Accepted] Soft Delete

[Nelsaidi]

Ticket: http://tracker.phpbb.com/browse/PHPBB3-9657
Patch: https://github.com/phpbb/phpbb3/pull/1017 (WIP)

New RFC by nickvergessen

Terms:

• Soft deleting:
  If a post is soft deleted by a moderator or user, it is not visible in the topic for normal users anymore.
  If the first post of a topic is soft deleted, the whole topic will no longer be visibile.
• Restore:
  Restoring a post/topic means to revert the soft deletion, so it's visibile again.

Configuration:

• Enable/Disable:
  This simple boolean config will allow managing soft delete with one option, rather than having to check all permission.
  • Default value: true

Permissions:

• New permissions:
  • m_softdelete:
    Moderator forum permission to allow soft deleting a post, which hides it from normal users
    • Default value: Copied from m_delete
  • f_softdelete:
    User forum permission to allow soft deleting own posts, which hides it from normal users. Could be used in order to disallow Users to delete their posts instead, moderators could then decide whether to really delete the post or not.
    • Default value: Copied from f_delete
• Modified permissions:
  • m_approve:
    The m_approve permission will not only be used for new unapproved posts, in order to approve them, but also for soft-deleted posts to restore them (revert soft-deletion).
    • Default value: Not modified

How to:

• Soft delete:
  Most might agree, that it would look a bit stupid to add a second delete button on each post. So I thought the following might be the best option:
  
  • Soft delete posts:
    Currently when you click on the X to delete a post, you are prompted with a confirm box, asking if you really want to delete the post. This Confirmbox would be modified to have 3 options, instead of Yes/No only:
    
    • Soft delete:
      Soft deletes the post/topic, so it can be recovered with "Restore".
    • Delete:
      Hard deletes the post/topic. the post/topic can not be recovered/restored.
    • Cancel:
      In case of a misclick or when the user decides not to delete the post/topic.
    If the user does not have *_softdelete, the soft delete option is not displayed, if the user does not have *_delete, the hard delete option is missing, and the Soft delete option is named "Delete" in order to avoid confusion.
  • Soft delete topics:
    Topics can be soft deleted, by:
    • Soft deleting the first post of the topic, or
    • Using the "Soft delete topic" option in the Quick-Moderation box.
    (Both actions have the exactly same result)
• Restore:
  • Restore posts:
    Posts can be restored by moderators in two ways:
    • Click on a "Restore" button, like it is currently done with unapproved posts, for approving them, or
    • In a MCP module within the queue category.
  • Restore topics:
    Topics can be restored, with performing the Restore post action for the first post of the topic.

Previous RFC bellow this quote box:

Hey Guys

First of all I'm not sure if this is an RFC, so put it here - if not move it or whatrver. Second of all I dont think 3.1 will have soft delete, hence this post - if it does then ignore it.

Soft Delete
Soft Delete is a feature only avaiable by mod for phpBB3, but exists in other forum software. Such a feature is in my opinion necesary, and many forums who do not have soft delete go through the trouble of splitting a post into another forum which brings disadvantages.

Though theres about 8 weeks until the phpBB3.1 date, I'm not sure if theres enough time for such an addition however this is what I propose (maybe this should be an RFC?)

About:
- Applies to topics and posts, and can be evolved to perhaps forums?

Configuration - On/Off:
- Soft Delete/Full Delete permision based on forums; option applies to all delete actions within that forum
- Global (forum wide) force soft delete/full delete option; as says would force the selected option - would be "Soft Delete", "Full Delete", "Forum Default"
- Forum 'Default' would be full delete - so admin must define soft delete; saves on database size from smaller forum admins or people no need for this

Proessing:
- As normal delete options, as in mcp/mass moderation or inline post
- AJAX post delete - Saves the extra page when deleting posts inline, confirmation window is a MUST despite undo being able since its only a soft delete. Makes mass inline moderation much quicker - Being asynchronous after confirmation the post block can simply grey out into that rolling image to show progress, then once its done formatting will be applied, if an error a dialog is displayed. Such a system would allow the moderator to hit post delete -> click yes -> do next post, etc etc - no need for the delete page
- Poster's post count would go down one, a 'void' or whatever field would determine whether the post has been deleted (so remains in the phpbb_posts table) - Not displayed for non moderators
- An additional permision for moderators "Display Deleted Posts"; determines whether deleted posts can be seen or not within forums they moderate.
- Further to the above, users who have deleted their posts cannot undelete (or perhaps a time limit to undelete?)
- Last Edit updated to the "<username who deleted this post> @ <time> - <user> soft deleted this post"

Purging/Full Delete of Soft Deleted Posts
- Eventually database size may become an issue, so purging is necesary
- Moderator Permision: Allow Deletion of soft deleted posts; lets moderators with this permisions fully delete (remove from db) posts which have been soft deleted
- Admin Panel - Purge soft deleted posts - gives time frame to delete, and perhaps forums to include/exclude?

Display:
- Admin must be able to distinguish easily between a soft deleted post; perhaps:
- Template would remain almost the same, however CSS would be used to identify identify posts:
- Reason for diffrent template would be something like a dialog to partially grayscale the post - this means images etc would be greyed out as they are displayed beneath a semi transparent block
- Buttons: Undelete, Full Delete

Thanks

[code reader]

soft delete can be implemented so easily and seamlessly that such a long discussion seems *almost* redundant. (it is not - the UI has to be discussed!)

i think i mentioned it in the past. the only sane implementation is to extend the "approval" mechanism a bit. currently, a post can be in a state of "not approved", which puts it (almost) exactly in the same category as "soft deleted": it remains in the table, it has its topic, poster, timestamp etc. all untouched - but it is not displayed.
the only change needed would be to extend the "approve" field to be extended from bit to a bitfield, and you are 85% done.

i know that you discuss functionality (absolutely needed) and i relate to implementation, but as long as soft delete is discussed, i just wanted to mention that any solution other than extending the "post_approve" bit to "post_status" bitfield will be wrong.

peace.

[naderman]

I agree that the best way to implement this is to change post_approved to a more general post_status field. What I am a little concerned about is query performance. I assume that the following query combinations all need to be possible: (1) approved & undeleted (2) all approved (3) all undeleted (4) all. The first one for regular users, 2 and 3 for moderators with one or the other permission and (4) for moderators with both permissions. Now with approved=1,deleted=2 this maps to the following SQL: (1) post_status = 1 (2), post_status = 1 OR post_status = 3, (3) post_status = 0 OR post_status = 1, (4) no filter. Now I'm not sure how well this performs with indexes on the table because of the ORs compared to adding a post_deleted column, where it would become (1) post_approved = 1 AND post_deleted = 0, (2) post_approved = 1, (3) post_deleted = 1, (4) no filter. Case (1) is certainly the most common so post_status seems better for that, but if the OR doesn't peform well for moderators who do use the board heavily that would be a big problem because it slows down the database for everyone.

[code reader]

since we do test the post_approve state *anyway* with all the performance sensitive queries on these tables (topics and posts) today, i do not believe there will be any effect on performance.
actually, this is the most compelling argument why the correct implementation would be to overload this existing field rather than create a new one (there are other, very good arguments to do it this way, but the zero-effect-on-performance is the most compelling one....)


peace.

[MichaelC]

I think the post un-approve function detailed here is quite similar so the discussion of it should be similar too:
viewtopic.php?f=81&t=32640

[Nelsaidi]

As said I think use of the post_status field would help as it links in to the post unapprove.

Performance coming to tihnk of it would be a hit but not too sure how much, possibly marginally. AAlthough comrpomises for performance are necesary, useful features phpBB lacking in shouldnt be comrpomised unless it adds alot.

Hmm, following onto what naderman said (also please correct me if I'm wrong), but is an OR entirely neceasry? Lets assume 1 means a normal post, and 2 - X (any number) are based on additional permisions, tihnk of it this way. Ordinary users (who cannot view deleted posts) just need "post_status = 1", moderators with additional permisions (would be as simple as viewing deleted/unapproved posts - since they are essentially the same) then post_status criteria isnt needed, but the value selected can be used to adjust options avaialable to that post.

[code reader]

Performance coming to tihnk of it would be a hit

no, actually, "coming to think of it" performance effect is exactly 0.
if you'll read my post above you'll understand why.

[EXreaction]

There is a performance difference when you move from a boolean to a bitwise field if you have separate permissions for viewing both options.

[naderman]

since we do test the post_approve state *anyway* with all the performance sensitive queries on these tables (topics and posts) today, i do not believe there will be any effect on performance.
actually, this is the most compelling argument why the correct implementation would be to overload this existing field rather than create a new one (there are other, very good arguments to do it this way, but the zero-effect-on-performance is the most compelling one....)


peace.

I'll have to try, looking at our schema our keys on the posts table are suboptimal anyway, so I guess it won't make a difference. Although we should probably improve those keys. I know that both bokt.nl and Arstechnica have improved them a bit but I'm not sure they could still be used efficiently when using OR in that way.

[code reader]

There is a performance difference when you move from a boolean to a bitwise field if you have separate permissions for viewing both options.

no there isn't.
both are stored as "int". the database does not have any facility to store any field smaller than one byte, and in most database systems, there is no performance penalty up to 32 bits (i..e, reading int(8) or tinyint is not more expensive than reading int(1) (or bit), and usually it is not cheaper than reading plain int).
the php code itself compares to "1", and it doesn't care if the comparison failed because it's 0 or because it's 2, 4, 8 or 3.
(the more reasonable implementation would change the "to be displayed" to 0, so 1 will become "unapproved", 2 would be "softdeleted" and 3 would be "unapproved AND soft_deleted. 4, 8, 16 etc. would be reserved for yet-to-be-defined status states).

the special screens, i.e. those of the moderators asking to see "all posts waiting for approval" are irrelevant as far as performance is concerned, but here, also, it will be *more* efficient, not less, to implement soft delete by means of a overloading an existing "status" flag rather introducing a new one.