"edit own issue" permission for documentation role

project_issue has a permission for this ('edit own project issues') but it's not enabled on d.o.

The basic reason is yeah, once it's posted, the email has gone out, and a lot of people read via the emails. So, if you keep editing the original post, no one sees any of the changes, just the original version you submitted which was emailed to them. If you want to add to what you said, make a new comment. If you want to fix what you wrote, that's what the preview button is supposed to prevent. ;)

In general, I notice a lot of people abusing the ability to edit their own comments. They regularly go back and revise what they wrote. Fixing typos or broken links is one thing. Changing your point over time as the issue debate unfolds is quite another... :/

So yeah, I'm not sure granting this permission to all authenticated users is a good idea. I fear it's just going to lead to more misuse, annoyance and confusion.

But, this isn't just for me to decide, so I'll let others weigh in before I change the status.

Cheers,
-Derek

Don't all authenticated users have the ability to edit their own issue comments anyway? If so, I don't really see how withholding this permission is protecting against the e-mail revision notification problem. The only thing it seems to be accomplishing is creating an inconsistent user experience since users on d.o can edit their own book pages, projects, and forum topics, so it's natural to assume they could edit their own issues as well.

Granting this permission would also provide a basic baby step towards #569552: Provide a mechanism for issue meta discussions. The author could keep the original node up to date with subsequent discussion as opposed to having to post a comment for this purpose, which is a hack I've seen employed in the core queue from time to time. Yes, I know that going back and editing stuff bugs the crap out of you as an e-mail subscriber, but people are going to do it regardless and looking for issue summaries in the *node* as opposed to comment #113 or whatever makes a heck of a lot more sense.

And if someone does decide to go 'rogue' with this permission, we have the role_activity to keep track of who edited nodes and comments and can fire off warnings or bans as needed.

+1 for the change here.

I completely agree with Derek. I read a LOT of issue stuff by mail, and people editing comments to do more than correct a few typos has caused me to not read their updated text.

Another way to do this would be to allow editing the node body via a comment. We've talked about making an issue summary field editable (and it actually could be the node body) in #569552-32: Provide a mechanism for issue meta discussions. That way it would be tracked instead of an anonymous edit.

Right. So.

We could wait for someone to code Mythical Unicorn Pony Comment Body Editor module.
Then we could then thoroughly review the module for best practices, performance, coding standards compliance.
Then we could go back and forth another 2-18 months fixing problems.
Then we could wait another 2-18 months for someone on the security team to have time to review it and give it the go-ahead.
Then we could spend one of the infrastructure maintainers' precious free moments testing and deploying it on drupal.org
Then we could spend the next 2-18 months fixing follow-up problems that only become obvious once the module is put into production

OR!

We could turn on a flipping checkbox.

:P

Also, if someone wants people to know they edited the node, it's real easy: post a comment that says "I just updated the original node to reflect these changes." Done.

Technology cost: 0 seconds.
Human cost: 5 seconds.

I'm also a grumpy "no edits" person with dww and merlinofchaos. It's true there is an inconsistency here - but we could also fix the inconsistency by a little change to drupalorg that prevents editing comments on issues.

@greggles: someone should have thought of that earlier. Oh wait, they did! ;) #306132: Add a permission that prevents users from editing issue followup comments

Meta issues are really a totally different situation here. We're going to need a totally different email model for those (or no emails at all). I'd rather not confuse this issue with "let's make issues sort of more like meta issues, since we don't have better meta issues right now".

@webchick: I appreciate the "better to have something crappy now than wait for something better which never seems to come" perspective. However, I really think this is a regression (as with comments). Issues are different than handbook pages and forum posts because they're the only node type on d.o that allows email subscriptions.

If you want currently-existing meta issue wiki pages, use a "community initiatives" handbook page. It's got everything you need:
- Anyone can edit (not just the original poster)
- The issue nid filter works
...

Ok, I'll grant you that about the community initiatives page.

It seems like the "correct" solution to both this issue and #306132: Add a permission that prevents users from editing issue followup comments that would satisfy both web users who do not want their ability to correct minor typos to be crippled by the fact that 1970s-era technology can't deal with it, and the users who live out of their inboxes in said 1970s-era technology ;), is to provide a configurable time window for editing nodes/comments that ranges to 0 (there is no time limit) to X minutes/hours/seconds. When the threshold expires, notification emails get sent, and the edit link goes away. Both web users and email users see the same, typo-free, picture of what got said.

I still think we should turn on the checkbox for this permission given the UX consistency problem (this question comes up on IRC at least once a month) while Magical Unicorn Timed Email Subscriptions gets coded, but it seems I'm out-voted. :\

The origial request talked about "projects" but the discussion then went to "project issues". What is ths about?

If it is about project issues, I am totally in the "no edits" camp. If it is about projects, then this a bug that needs fixing.

It's not just an e-mail issue, I use the web interface for 90% of the projects I follow. I often read issues quickly after they are posted. Then they are marked new again which confuses me and I have no way of knowing what detail of the comment was edited. If we prevented comment editing, I'd always know what was changed.

which any responsible person editing their comments (or project issue?) usually does

But what percent of the total population are these mythical "responsible" creatures you mention?

I'm in favor of adding this permission to the "documentation team" role. I know that having this could help the life of several module maintainers or top contributors that are not (and don't want to be) site maintainers.

I can agree with #15.

+1 to #15 as well. What's the right place to document sirkitree's "responsible behavior" ?

If someone made a module that made users require approval for content editing or a notification feature was existent, then that might solve the problem. Workflow might work. I haven't used it, but I have Kaltura Media Management. That might do it also.

@Soren Mortensen: I don't fully understand what you are proposing here? Do you want to work on such a module?

I am not going to deploy anything affiliated with Kaltura on d.o.

Approval is a bad way to go, IMO, it doesn't really help anything.

I'm just going to +1 #15 as well. This is really hurting me on a few issues right now.

Nobody who weighed in here has been opposed to granting that permission to the docs role. Updating title to make this more clear and I think we should do this in the next day or so unless we hear an objection. It's easy to revert if someone dislikes it.

I can live with #15 as well.

Sorry.

Issue summaries means you can edit any issue. And to documentation role no longer exists.