Last modified: 2014-11-15 02:17:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13937 - Correcting edit summaries (if own, last, & recent)
Correcting edit summaries (if own, last, & recent)
Status: NEW
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
unspecified
All All
: Low enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 20511 (view as bug list)
Depends on: 10105
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-03 19:11 UTC by Cacycle
Modified: 2014-11-15 02:17 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to introduce PageHistoryTool hook (495 bytes, patch)
2008-07-07 02:10 UTC, Nigel Jones
Details
Correct patch (499 bytes, patch)
2008-07-07 02:14 UTC, Nigel Jones
Details
Rebased patch w/ hooks.txt documentation (1.04 KB, patch)
2008-08-13 12:25 UTC, Nigel Jones
Details
Rebased patch (r39564 w/ updated hooks.txt documentation and tabulation instead of spaces (1.03 KB, patch)
2008-08-18 00:46 UTC, Nigel Jones
Details
Empty diff table alignment in Firefox (66.31 KB, image/png)
2010-01-10 16:32 UTC, Derk-Jan Hartman
Details

Description Cacycle 2008-05-03 19:11:30 UTC
I propose to implement a mechanism to correct edit summaries (1) if it is your own edit (2) and if it is the last edit (3) during a short time span (e.g. 1 - 12 hours).

One possible way to do this would be a link on history pages, e.g. "(rollback | undo | fix summary)". A new page would then allow to fix the summary.

Such a function would allow to fix accidents such as empty summaries, switched summaries (when you have many tabs open), and half-completed raw summaries. Currently, minor or fake edits are required to provide a correct summary.

Under the proposed restrictions (own, last, recent), there is probably no potential for abuse (e.g. any following edit would make the previous summary permanent). This would allow to simply overwrite the edit summary field without the need for a summary history or log.

This might have to be restricted to registered users as theoretically an anonymous user with reassigned IP would be able to change summaries not belonging to him.

There is a current Village Pump proposal (http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Being_able_to_edit_your_edit_summaries) with currently only positive responses.

There is a also somewhat related closed bug (https://bugzilla.wikimedia.org/show_bug.cgi?id=10105) which did not discuss reasonable restrictions or implementation details. The current proposal addresses previous objections such as increased user interface, system, or code complexity.
Comment 1 Brion Vibber 2008-05-07 00:56:50 UTC
We've generally blanket-rejected these requests in the past.

Might not be a bad idea to be able to handle the "oops" factor gracefully, though.
Comment 2 The Duke of Waltham 2008-05-27 00:18:44 UTC
What do you mean?

And, for the record, I do not like the sound of "blanket-rejected". It indicates a lack of willingness to examine the specific proposal on its merits. The strictest limit, one hour, would allow for all the benefits and would completely exclude any possibility of abuse (RfAs and RfArs have been cited mostly); I could even say that some misunderstandings might be avoided by editors changing a potentially offensive summary immediately afterwards, regretting their quick temper.
Comment 3 Cacycle 2008-05-31 23:31:32 UTC
The proposed mechanism has been implemented in most online forum systems (such as phpBB) postings and has proven its usefulness and safety for years.
Comment 4 Nigel Jones 2008-07-05 15:08:38 UTC
Just an FYI, I've actually been working on an extension that'd allow this to happen, it needs a bit of a cleanup, and I need some sleep, so I'll post it online sometime soon.
Comment 5 Nigel Jones 2008-07-07 02:10:32 UTC
Created attachment 5054 [details]
Patch to introduce PageHistoryTool hook

(In reply to comment #4)
> Just an FYI, I've actually been working on an extension that'd allow this to
> happen, it needs a bit of a cleanup, and I need some sleep, so I'll post it
> online sometime soon.
> 

Current code is online at http://dev.nigelj.com/mw/ it still needs a little bit of fixing, but it's nearly there.

Note, it requires the patch attached to work (n.b. changelog entry and hooks.txt edit removed in order to apply cleanly).
Comment 6 Nigel Jones 2008-07-07 02:14:20 UTC
Created attachment 5055 [details]
Correct patch

Oops sorry folks, the last patch added an extra hook arguement that is by no way needed, here is the correct one.
Comment 7 Huji 2008-07-07 13:52:35 UTC
Nigel, I think a better (more generic) name should be used for the hook. Other than that, I find the idea useful.
Comment 8 Nigel Jones 2008-07-10 22:38:55 UTC
(In reply to comment #7)
> Nigel, I think a better (more generic) name should be used for the hook. Other
> than that, I find the idea useful.
> 

Yeah, I agree whole heartedly.

Naming it SpecialFixsummary would be a better choice (which I've now done locally).
Comment 9 Nigel Jones 2008-08-13 12:25:09 UTC
Created attachment 5174 [details]
Rebased patch w/ hooks.txt documentation

I've rebased the patch, just need to finish updating the extension etc, hopefully do that this weekend.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-13 16:47:04 UTC
The added hook seems relatively reasonable, independent of the merit of the request that this bug actually makes.  Use tabs, though, not spaces.  And you're missing documentation for the PageHistory object (first parameter passed) in hooks.txt.
Comment 11 Matthew Flaschen 2008-08-16 06:57:00 UTC
I think the basic idea is worth considering, but an hour is far too long.  Five minutes should be a maximum.  Anything more would be too confusing, in my opinion.
Comment 12 Siebrand Mazeland 2008-08-18 00:29:07 UTC
Keywords: patch, need-review
Comment 13 Nigel Jones 2008-08-18 00:46:06 UTC
Created attachment 5188 [details]
Rebased patch (r39564 w/ updated hooks.txt documentation and tabulation instead of spaces

(In reply to comment #10)
> The added hook seems relatively reasonable, independent of the merit of the
> request that this bug actually makes.  Use tabs, though, not spaces.  And
> you're missing documentation for the PageHistory object (first parameter
> passed) in hooks.txt.
Done in this update 

(In reply to comment #11)
> I think the basic idea is worth considering, but an hour is far too long.  Five
> minutes should be a maximum.  Anything more would be too confusing, in my
> opinion.
I agree, I plan in my next update of the extension to allow it to be customized.

Unfortunately I got distracted with other more important issues this weekend hopefully I'll be back onto this, this week.

(For reference, this hook allows the extension to hook in next to Rollback etc)
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-18 17:19:45 UTC
Looking over the code, I think that a more comprehensive hook to replace the current PageHistoryLineEnding hook (while still keeping that for backward compatibility) would be a good idea.  Currently we collapse everything into a string before we pass it to the hook, which is stupid.  Instead, we should ditch the $s variable, and have the ending be something like this:

$ret = null;
if( !wfRunHooks( 'EndPageHistoryLine', $this, $row, $next, &$arr, &$ret ) ) {
	return $ret;
}
return '<li>' . implode( ' ', $arr ) . "</li>\n";

This still has some issues:

* Do we guarantee what numeric index various array elements have, or what?  There are like ten or twenty different items going into this line, which makes for a really complicated single hook.
* Imploding on spaces doesn't help with things like $tools that should really be passed as arrays themselves.

I don't think adding one extra hook for every widget on the line we want to be able to modify is a good idea.  Is there any way to elegantly and simply expose *all* of this info to hooks?
Comment 15 Siebrand Mazeland 2008-11-09 11:09:46 UTC
Issues raised in comment 14 need to be addressed.
Comment 16 Nolan White 2009-09-05 17:10:48 UTC
*** Bug 20511 has been marked as a duplicate of this bug. ***
Comment 17 Derk-Jan Hartman 2010-01-10 16:32:37 UTC
Created attachment 6944 [details]
Empty diff table alignment in Firefox
Comment 18 Derk-Jan Hartman 2010-01-10 16:37:35 UTC
sorry, image was for anther bug.
Comment 19 Sumana Harihareswara 2011-11-04 19:12:30 UTC
Changing keywords since Aryeh did review the patch.
Comment 20 James Forrester 2014-11-13 16:53:23 UTC
This very clearly isn't just "related" to bug 10105, but depends on it; this is merely modifying the default rights set for the functionality requested in bug 10105, so discussion should remain there.
Comment 21 John Mark Vandenberg 2014-11-14 02:15:44 UTC
Note that https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement provides similar functionality without the dependency on bug 10105

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links