Last modified: 2014-09-24 01:04:02 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 6315 - When clicking the delete link you should be warned if page has changed since you loaded it
When clicking the delete link you should be warned if page has changed since ...
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Page deletion (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-15 08:47 UTC by Sherool
Modified: 2014-09-24 01:04 UTC (History)
4 users (show)

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


Attachments

Description Sherool 2006-06-15 08:47:52 UTC
Simmilar to edit conflict resolution. If you are editing a page and it's deleted in 
the meantime you get a warning when trying to save asking if you wish to recreate or 
not. However the reverse seems to now apply. If you opened a page, and then click 
the delete link you will not be warned if someone updated the page in the meantime.

I just had this happen to me on enWiki. I found an albumcover tagged as "no license" 
in a more than 7 days old deletion category (speedy deletion criterea). So I edited 
the image to add source description and license tag and removed the deletion 
template. However 8 minutes later someone deleted the image as "no license" anyway. 
What I guess happened was the admin opened all the images in the category in a lot 
of different tabs in his browser and worked his way though deleting them, so as far 
as he knew the image was still tagged as "no license" when he deleted it, and he 
never knew the license issue had been fixed.

The solution seems to be to send the revision ID or last change date or whatever 
along with the delete link so that if the admin for whatever reason linger long 
enough on the page for someone to change it before he click the delete button he 
will be given a warning that the page have changed since he last saw it and ask him 
to review wether he still want to delete it or not. Same goes for when "executing" a 
deletion I guess.

It's a fairly rare situation, but can be anoying when it happens.
Comment 1 Kevin Breitenstein 2006-07-07 01:10:18 UTC
Suggest then that it be made similar to image uploads.  Wherein the admin can
also click 'ignore warnings' when deleting something, else they get a special
confirm page where they can go back to the page in question and view it or just
click a continue button.
Comment 2 Rob Church 2006-07-07 01:14:54 UTC
I'm more inclined to pass the revision number along with the deletion form, and
check the current revision number against the master prior to performing the
deletion; if it differs, the user can be taken back to the deletion form with a
simple warning. Confirming the deletion a second time will go ahead and delete it.

The check could be suppressed as an option, if desired.
Comment 3 Sumana Harihareswara 2011-10-07 21:14:42 UTC
The situation is still possible as of MediaWiki 1.18.  I tested both in the case where the article had changed since I last loaded it, and in the case where the article had changed since I had moved to the deletion screen.  In neither case did MediaWiki warn me that the article had changed since I made my decision to delete.

Adding "design" tag so a UI designer can think about the best way to implement this warning.
Comment 4 Nemo 2013-03-06 09:29:46 UTC
(In reply to comment #2)
> I'm more inclined to pass the revision number along with the deletion form,
> and
> check the current revision number against the master prior to performing the
> deletion; if it differs, the user can be taken back to the deletion form
> with a
> simple warning. Confirming the deletion a second time will go ahead and
> delete it.

Makes sense.

Not a design issue at all, we already have this sort of warnings (the page was protected, it was deleted before, etc.); plus, nobody cares if sysops see ugly warnings when deleting something.
Comment 5 balloonguy123 2013-05-15 22:40:33 UTC
I've got this working for pages by passing the current revision id in the deletion form generated by Article::confirmDelete, and then checking to see if the current revision id has changed in Article::delete prior to calling Article::doDelete for deletion, emitting a warning if necessary and prompting for reconfirmation by calling Article::confirmDelete again with the new revision id. This will add a new message, do I just add it to Messagesen.php?

However, the initial bug report involved the deletion of files and I am having trouble implementing the warnings for files. The deletion form is generated by FileDeleteForm via ImagePage. I can't determine how to get the revision id for the page associated with a file and add it to the form in FileDeleteForm::showForm and then get the current revision id again in FileDeleteForm::execute to compare. ImagePage has a mPage attribute but it is an instance of WikiFilePage that doesn't have any methods for getting the revision id.
Comment 6 Gerrit Notification Bot 2013-05-19 19:56:10 UTC
Related URL: https://gerrit.wikimedia.org/r/64533 (Gerrit Change Ifc962130a1e2ef62b18384b13f6c0e8320819a79)
Comment 7 Matthew Flaschen 2013-05-20 20:13:40 UTC
(In reply to comment #5)
> I've got this working for pages by passing the current revision id in the
> deletion form generated by Article::confirmDelete, and then checking to see
> if the current revision id has changed in Article::delete prior to calling
> Article::doDelete for deletion, emitting a warning if necessary and prompting
> for reconfirmation by calling Article::confirmDelete again with the new
> revision id.

This is similar to how edit conflicts work, and probably sufficient.  However, it's a little different from the initial request.  That said:

"I guess happened was the admin opened all the images in the category in a
lot of different tabs in his browser and worked his way though deleting them"

To handle that scenario, I think it would be necessary to pass the revision ID in the delete link.  It would be optional, and if omitted would fall back on the last revision ID as of the time the deletion confirmation form is shown.
Comment 8 balloonguy123 2013-05-21 21:57:23 UTC
I addressed this case as you stated by passing the revision id in the delete link. However, I show the message when the deletion confirmation form is first loaded, instead of waiting for the form to be submitted. This still does not handle a file being edited while it was being deleted.
Comment 9 Andre Klapper 2014-02-19 10:04:53 UTC
Balloonguy: Do you plan to rework your patch in Gerrit?

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


Navigation
Links