Screen comment edits when comments are screened

[tim]

Title:
Screen comment edits when comments are screened

Area:
comments

Summary:
Right now, if I set comments to screened-if-not-in-my-circles and I unscreen a comment, then the author edits a comment, the edit appears immediately without being screened.

Description:
I have screening enabled by default in my journal for comments from people not on my access list. Suppose "Alice", who's not on my access list, leaves a comment, and I unscreen it. If "Alice" edits the comment afterward, her edit appears immediately -- I don't have to unscreen the new edited version.

This is weird. When I saw this happening, fortunately the edit was just a typo fix. But in general, a commenter could abuse the editing feature to sneak in an edited version of the comment that the journal author wouldn't have unscreened.

I think when someone edits a comment in a context where screening is active, their edit should be like a new screened comment: that is, the old version should appear until the journal owner unscreens the edit (at which point the old version goes away).

Poll #11717 Screen comment edits when comments are screened

Open to: Registered Users, detailed results viewable to: All, participants: 53

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
27 (50.9%)

Should be implemented with changes. (please comment)
9 (17.0%)

Shouldn't be implemented.
2 (3.8%)

(I have no opinion)
15 (28.3%)

(Other: please comment)
0 (0.0%)

Comments

[syderia]

With changes because maybe there should be a note on the old comment that it has been edited and the edit is waiting to be unscreened.

[swaldman]

OTOH, what if the commenter is really embarrassed about the pre-edited version... I'm tempted to suggest that this could be an option when saving the edit...

[azurelunatic]

I've observed no few edits being made because the commenter realized that they'd said something that they maybe didn't mind me knowing or would have said to me in a more private forum, but that contained information that didn't need to be shared with the whole internet.

Leaving the old version up would be enough of a change to expected behavior that if this happened, there should be something explaining what would happen on the edit screen.

Someone who's not okay with having the old version remain up would still be able to do the poor user's edit, the delete-and-repost.

Hi! *waves*

[marahmarie]

I believe I'm "Alice". But yeah, I totally voted for this. It's a good idea. If a comment was screened in the first place, the comment owner could edit the comment, once un-screened, to say anything and because the edit flies without re-screening, the journal/comm owner can and maybe will lose control of the comment threads. Serious issue. I think we used to automatically re-screen on LJ in this event (I was just reading an old LJ comment exchange on my own blog that seemed to address this very issue) but I'm not entirely sure.

Re: Hi! *waves*

[denise]

No, the behavior's the same on LJ. (Implementing this would actually require a heck of a lot of work to change the screening behavior, in fact. Which is not a reason not to do it, just a note.)

[ninetydegrees]

I voted no because the current behavior makes sense to me but I don't use screening much so it's more of a hmm, no for me but I'd be fine with whatever everybody else prefers. :)

[pseudomonas]

Actually, I think what I'd also like is an option that says "allow the person who posted this (presumably the person with the right browser cookie)" to bypass screening on this post in future. This needs to be a separate suggestion, though, and I realise it'd probably be way fiddly to implement.

[azurelunatic]

I like the "on this post" refinement.

[pseudomonas]

Or possibly in general, I guess, but that feels like not the right thing to be using cookies to allow an anon-user to do.

[azurelunatic]

Ah, I was picturing logged in users, in part because I have anonymous commenting turned entirely off.

[pseudomonas]

Either way. For long-term interactions with someone, the idiomatic way to do it is to grant them access via either a DW account or OpenID (or equivalent). But for someone that shows up making interesting comments and getting into a good discussion, you don't want to put the brakes on that more than necessary by having to unscreen every comment.

Part of me wonders if this would tie into plans to have anon users give a pseudonym rather than just all be "anon".

[matgb]

FWIW, comment editing finally came in after a lot of pressure on J, but was largely in response to my suggestion of broadly what happened, however in comments this was covered (By Azz, as it happens) here

azurelunatic (from 68.227.245.34)

January 9 2007, 07:27:27 UTC
Regarding abuse of the comments: if a comment was screened to start with, then unscreened, an edit would re-screen it.

matgb (from 193.69.116.84)

January 9 2007, 07:32:13 UTC

Good catch. I rarely if ever feel the need to screen comments so covering them didn't occur to me.

azurelunatic (from 68.227.245.34)

January 9 2007, 07:41:55 UTC

I have a community with non-member posting screened, to avoid dogpile flamewars.

I don't know why it wasn't implemented originally, I'm guessing coding time rather than desirbability but might be wrong, and think it's almost certainly a good idea,with a proviso that some way of making it unnecessary for minor edits, maybe involving trusted friends or something?

I'd hate to have to re unscreen someone who makes a bunch of typoes, fixes them, then sees they've put a comma in the wrong place.

[montuos]

I agree that when comments are screened, edits should also be screened, because I have seen in other milieus how people can abuse editing ability by changing things substantially when they edit.

I do not agree that the old version should remain while the new version waits to be approved; the whole point of editing is that the old version was deemed unsuitable by the writer.

[susanreads]

With this in mind, I think re-screening the whole comment (rather than just the edit) would be better.

[turlough]

Yeah, it's the only alternative that makes sense to me.

[montuos]

Ok, now I'm confused! I thought editing comments simply replaced the content of the original comment field? Well, apart from adding the "edited" notation/timestamp and optional reason, that is.

[denise]

It does, yeah, hence the complications that would be part of implementing this!

[zing_och]

+1

[triadruid]

Exactly. It feels like a bug that it doesn't do so now.

[elf]

I have no direct opinion (anon comments are screened on my journal, which can't be edited anyway), but wanted to say that I'm in favor of extra screening options in general. (Don't screen particular users. Optionally rescreen after edit. Indicate that comments are screened before the commenter hits "post." Notify when comments have been unscreened. And so on.)

I don't think rescreen-after-edit, or optionally-rescreen-after-edit, hits the "too many options" problem too badly, because default users aren't going to notice screening *exists* until they run into it on someone else's journal. As a kind of "advanced user" option to start with, extra options aren't likely to be too confusing. Screening is already a weird/touchy feature (an awesome one, but sometimes confusing), and I'd like to see it modified in directions that more people are happy with.

That, of course, has nothing to do with how complicated the coding would be.

[tim]

Yes, I'd at least like a third level of security: ignoring filters, currently DW has two levels of security, no permissions and "allowed to see your locked posts" (with Grant Access), but it would be nice if there was "allowed to comment without being auto-screened", as well, which could be granted without granting access. I've suggested something like this before, but gotten shot down. I think it would be useful, though, for people who run more of a "blog" (with lots of people commenting, who you don't necessarily trust with your personal secrets but who you're OK with allowing to comment) than a "journal" (for a group of trusted friends and no one else).

[elf]

I suspect it's a too-complicated level of either coding or UI hassles, but I do like the idea.

(I also want a "post is only viewable by logged-in people" option, but that got shot down as too likely to be confused with real security. Features designed to invoke headaches in the support staff get extra scrutiny.)