Last modified: 2014-09-24 01:04:02 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.
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.
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.
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.
(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.
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.
Related URL: https://gerrit.wikimedia.org/r/64533 (Gerrit Change Ifc962130a1e2ef62b18384b13f6c0e8320819a79)
(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.
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.
Balloonguy: Do you plan to rework your patch in Gerrit?
