[RFC] Post Revisions

[imkingdavid]

If they have to worry about database size, then they should set a limit to the number of revisions stored to help control it. Users are not going to be able to manage space simply by deleting old revisions they think are unnecessary manually, that would be hours of work for a couple of MB at most. An average post revision might be what on average, 1-2Kb? I don't think anyone is crazy enough to manually delete 500 posts to save 1Mb of data...

Agreed, but it's not just about managing space. Consider a Wiki post, and presume that users can see all revisions of Wiki posts. Assume that some user posts a spam or warez link in the Wiki post. Does it make sense to edit the post to remove the link, knowing that users can still see the link in the revisions? I think that it makes more sense to delete the revision.

Steve

Well, that is a fair point, although I would argue that if someone posted warez, editing their post would not be the first response from me; I would instead delete their offending posts and then ban the user. But yes, I agree that it could be handy to have a way to delete an individual revision. But given the feedback I've gotten so far, I don't think it should be as easy to do so as it it currently is.

[EXreaction]

Fair point on the wiki posts, there should be at least some way to hide edits that could be offensive (whether that would be by deletion or what I am not sure).

If they were a spammer and you just wanted to delete their posts, their post revisions on wiki posts might need to be removed (either reverted to the previous revision if it's the newest, or just deleted if it's older).

[naderman]

Well, that is a fair point, although I would argue that if someone posted warez, editing their post would not be the first response from me; I would instead delete their offending posts and then ban the user. But yes, I agree that it could be handy to have a way to delete an individual revision. But given the feedback I've gotten so far, I don't think it should be as easy to do so as it it currently is.

It definitely should be possible.

I'm saying that to delete revisions you delete the post. Deleting the source post should trickle down to delete all revisions of that post. If it's important enough to keep revisions, then keep them as long as the post is around.

That's like saying to delete a post, delete the topic. Deleting the source topic trickles down to delete all posts of that topic. Which is entirely different from what you wanted, namely to delete one post.

As for search I really think that's going too far. This will make search backends vastly more complicated. I think search should stick with searching only the current versions of posts.

[Pony99CA]

If I delete a user and check the option to delete posts, I presume that will also delete revisions to their posts, but what about that user's revisions to Wiki posts that they did not start?

If I keep the user's posts, I presume that user's name will be preserved on revisions, too, not just posts.

Steve

[imkingdavid]

If I delete a user and check the option to delete posts, I presume that will also delete revisions to their posts, but what about that user's revisions to Wiki posts that they did not start?

If I keep the user's posts, I presume that user's name will be preserved on revisions, too, not just posts.

Steve

I think currently deleting a user deletes all revisions by him. It is a good point you brought up that only the revisions on that user's own posts should be deleted. So that user's revisions on other posts and wiki posts not created by him will be kept.

[drathbun]

Assume that some user posts a spam or warez link in the Wiki post. Does it make sense to edit the post to remove the link, knowing that users can still see the link in the revisions? I think that it makes more sense to delete the revision.

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

"Look, for your protection we audit all changes, so if a rogue moderator goes about editing your posts, we can find out why."
"Oh, except when we want to delete the revision because it serves our purpose."



That's an extreme case, I guess. And what you do here is completely up to you. But I can say that for my own implementation, revisions are what they are, they're part of the history of that post. If the post is removed, the audit trail is removed. But as long as that post remains, then all of the revisions will remain as well.

If someone goes nuts and makes 500 revisions, they'll get blocked or banned and their posts will be removed. Simple enough.

As I mentioned, if you search on words that you remembered were in the post, it might matter. For example, if a moderator remembered that some user had used a racial slur in the past, but wasn't sure it was the member who had just used one now, he might want to search on that slur to decide if he should issue a warning to the user. However, the original post would probably have been edited to remove the slur, but the slur would be in the revisions.

Maybe I should be more clear on what I meant. I don't believe revisions should come up in the standard search results. But if there were to be a separate feature to search only revisions, that might be okay. I don't see that it would ever get used (your scenario notwithstanding) but something like that could be built. For as often as I think it would be used, I'm not sure it's required. And it would not have to be part of the initial release because it would be a completely separate process, at least the way I'm envisioning it. The standard search process works on post text, which is stored in one table, and revisions are stored in a separate table. So because of that separation, the search process would need to be separate as well. If it were going to delay the release of the post revisions feature, I would rather see post revisions out sooner without it, and add a search feature for revisions at a later date. Just my preference.

[psoTFX]

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

This.

[MichaelC]

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

This.

-1, so we shouldn't give users an option? Every admin has his own preferences about how he/she runs his/her board.

In my opinion, there are some posts this feature is useful for (information posts), but some not so much so in which having a public post history might not be a good thing (abuse), in which case the revision can be deleted at discretion of the board staff. When soft delete is implemented (there is a PR that needs conflicts solving etc but does exist), then it might be a good idea to be able to soft-delete revisions (so viewable to staff but not public) as well as hard delete them.

Its helpful to be able to delete things. Logs, posts, reports, PMs, users, forums, attachments, ranks, smilies, extensions, avatars. Why not revisions? When you think about it, it would be the only thing of its sort (things that can be deleted), that wouldn't be delete-able.

There is nothing wrong with giving forum admins a choice on how they decide to moderate their board. Its like saying, you can just split off posts to a trash bin, why would you need a delete post function.

[Pony99CA]

Assume that some user posts a spam or warez link in the Wiki post. Does it make sense to edit the post to remove the link, knowing that users can still see the link in the revisions? I think that it makes more sense to delete the revision.

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

Besides what Bliss said (which I completely agree with), if you view revisions as a true audit trail, then there should not be a Purge All Revisions feature or a depth limit (as you previously said). So how about a compromise -- have Can protect revisions and Can delete revisions Moderator permissions. Then people who like true audit trails can prohibit deleting revisions and people who aren't that hard-line can allow it.

Of course, if you believe in true audit trails, I presume that you never clear the various phpBB logs and never give other admins permission to do so, right? Personally, I clear out lots of things in logs, only keeping the items that I judge are worth preserving, and would treat revisions the same way.

But I have no problem with admins who may choose to do things your way -- as long as we both have the option to do it the way that we want.

That's an extreme case, I guess. And what you do here is completely up to you. But I can say that for my own implementation, revisions are what they are, they're part of the history of that post. If the post is removed, the audit trail is removed. But as long as that post remains, then all of the revisions will remain as well.

If someone goes nuts and makes 500 revisions, they'll get blocked or banned and their posts will be removed. Simple enough.

Not true. If their 500 revisions were made to Wiki posts that they didn't start, deleting their posts won't be sufficient.

As I mentioned, if you search on words that you remembered were in the post, it might matter. For example, if a moderator remembered that some user had used a racial slur in the past, but wasn't sure it was the member who had just used one now, he might want to search on that slur to decide if he should issue a warning to the user. However, the original post would probably have been edited to remove the slur, but the slur would be in the revisions.

Maybe I should be more clear on what I meant. I don't believe revisions should come up in the standard search results. But if there were to be a separate feature to search only revisions, that might be okay. I don't see that it would ever get used (your scenario notwithstanding) but something like that could be built. For as often as I think it would be used, I'm not sure it's required. And it would not have to be part of the initial release because it would be a completely separate process, at least the way I'm envisioning it. The standard search process works on post text, which is stored in one table, and revisions are stored in a separate table. So because of that separation, the search process would need to be separate as well. If it were going to delay the release of the post revisions feature, I would rather see post revisions out sooner without it, and add a search feature for revisions at a later date. Just my preference.

I've agreed that searching isn't important if it delays things -- phpBB searching would still work just like it does today. I just want people to consider searching in the design.

As for two separate tables, I may have skimmed over things too much, but wasn't there some discussion about whether revisions would be stored in the posts table (especially being full-text) or a separate table? If they're in the posts table, you'd have to do extra work to avoid revisions.

Presumably the separate table idea won out, but you could still do with search from the main page (SQL has a UNION operator). The hard part would be designing how to display the revisions -- the search text could come from the current post only, one or more revisions only, or both.

However, as nobody else seems interested in this, we can put it off for a future RFC and forget about search for now. As I said, I just wanted people to consider it, which has now been done.

Steve

[imkingdavid]

Assume that some user posts a spam or warez link in the Wiki post. Does it make sense to edit the post to remove the link, knowing that users can still see the link in the revisions? I think that it makes more sense to delete the revision.

Taking a hard-line stance here... but this is something I've thought about for a while. I don't see the point of deleting revisions, in fact I believe it defeats the entire purpose of this feature. If you're going to set up an audit trail, and that's how I view this, then you can't selectively decide to audit some things and not others. If you track revisions, you have to track everything, warts (aka spam links) and all. A partial solution is a placebo.

Besides what Bliss said (which I completely agree with), if you view revisions as a true audit trail, then there should not be a Purge All Revisions feature or a depth limit (as you previously said). So how about a compromise -- have Can protect revisions and Can delete revisions Moderator permissions. Then people who like true audit trails can prohibit deleting revisions and people who aren't that hard-line can allow it.

I suppose that's the best solution, to add permissions.