I'm not a big fan of this. Essentially, when you can go back and "rewrite history", there's all sorts of potential problems. People will start off a thread with an inflammatory post, and then go back and edit the content, changing the context for all posts that come after it. It's better that a thread is locked or removed if this is a concern.

Spelling errors is something you'll have to live with if you weren't paying attention when you previewed your post. ;)

Also, I'd like to integrate Ploneboard with mailing lists to have a two-way interface (you can either use mailing list or the forum as your interface), and I'm not sure how you would pull off editing posts in that context.

If it does get added, it should at the very least be disabled by default.

Sorry, but I inadverntently deleted the comment by elvix:

"I agree 100% with Limi here. Editing posts is a backwards way of thinking regarding boards. IMO it is a "we-need-it-because-PHPbb-has-it" feature. - The reason Plone is great is not by copying bad UI paradigms, but by "righting" them. Let's not be any worse when it comes to Ploneboard than we are with Plone itself."

My comment, from my experience managing boards for about 15 years, is that users actually do like the option to edit their posts if needed, and not for the purposes of evil. This should be a core feature, and turned off by default. Users can edit their own content already in most content types, so this is just extending this option to forum conversations and replies.

Deleting posts are another topic altogether. these should be retractable, with the admin as the deleter if they agree.

Marshall

I am very sensitive to the concerns about "rewriting history." As I also am to users' very real desire to be able to edit their posts for legitimate/good reasons, such as correcting errors, etc. It's a real tension with valid arguments on both sides.

I have noticed that leading open-source forum tools take the following approaches to resolving this tension:

• phpBB appears to tag comments with an "edited at TIME" if a user edits a comment after posting, to alert readers that history was changed.
• Drupal allows users to edit only their last comment, and then only if no other comments have been posted since.

Both approaches seem like reasonable "compromise" solutions to me.

I definitely think that admins should have the option to allow or not allow user editing. And I would be perfectly happy if that feature defaulted to "off."

Many Plone content types include this information as part of the visible meta data. I would go with this, and of course hvbe the default for editing/retracting posts by members be turned off.

I am working on a branch of Ploneboard (zest-ajax) and have the edit button available only on the last comment on a thread for the owner of that comment and the manager has edit on all comments for moderation purposes. Same goes for the delete button.

Reading the discussion I think this is the most common use case.

BTW: We (Jladage and RockyBurt) have also implemented AJAX for replying, editing and deleting comments.

Sounds like a great step forward!

I think the best way is adding the complete editing history like in most wikis. I use Ploneboard and my users are demanding such a feature. But it should be off by default IMO.

I agree with Limi and Elvix. I'm also interested in using Ploneboard as a more generic threaded-discussion holder, having different interfaces to get at the content.

FWIW, I don't consider the existing retracted workflow state to be a "stub" feature. Reviewers see a greyed-out post, but other users simply see a message saying that post has been retracted... at least that should be what is happening.

Tim

Tim,

RE: "stub" retract feature

I stand corrected. Retracted comments are censored for non-reviewer users. This wasn't obvious to me at first.

Here is the current state of affairs:

o Delete works
o Edit works
o Retract works
o Re-publish works

By default, only manager can delete and edit, and manager and reviewer can retract and re-publish. Delete does not re-patriate child replies (since the context is lost anyway, and there is generally no sensible way of knowing which parent to patriate it with). Retract hides a comment from anyone except owner, reviewer and manager.

Now: The buttons work. The workflows manage permissions for Delete, Edit, Retract, and Approve (re-publish, or publish in the first place). They can be customised (with a bit of careful testing) to your use case, but for the default behaviour, we take the safe approach. :)

Martin