Last modified: 2014-10-05 19:58:36 UTC
Created attachment 12764 [details] Screenshot of the notification - I recently posted a deletion request to [[:en:File:SCAS Logo 2006.svg]]. - The deletion request was reverted, therefore I recevied a notificationvia Echo. - The request was accepted later (since it actually was valid) and the image was deleted. Now Echo shows > Your edit on [[:[No page]]] has been reverted by Magog the Ogre (A/Com-A) [No page] instead of the correct message with a) a correctly linked page (which would be a redlink now, but that shouldn't matter) and b) the edit summary given on revert (which might be harder though, since it's not publicly visible anymore after page deletion)
This affects other notifications as well, I've seen it happen to link notifs.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/223
*** Bug 54525 has been marked as a duplicate of this bug. ***
*** Bug 58759 has been marked as a duplicate of this bug. ***
Changing priority to normal, lowering severity to normal since that's not that annoying a bug (though I've just experienced it).
I just noticed this on the English Wikipedia ("Salinger (film) was linked from [No page].").
(In reply to comment #5) > Changing priority to normal, lowering severity to normal since that's not > that > annoying a bug (though I've just experienced it). I disagree. I see this regularly, and it is infuriating to know there is a deleted page, but need to go poking around in the watchlist of days ago to find it. In the case of Wikidata, after finding which Q it was from the watchlist, you need to use whatlinkshere to guess what the Q's label was.
I'm bumping this up to High again, because Echo's inability to handle deleted pages is a potential problem for every other extension that tries to implement Notifications. As I understand it, Echo typically stores the pageID rather than the plain title of a page when it records a Notification, and if a page gets deleted then it doesn't have permission to access the properties of the deleted page, such as the title. Finding a way to let Echo access the titles for deleted pageIDs might be a solution.
Just to elaborate a bit on what Sage said ^ , this issue came up with regard to a notification in the Education Program extension. See: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEducationProgram/520430baeb85384bab46442ef654ec043a4c0b5b/includes%2Fnotifications%2FCourseTalkNotification.php and https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEducationProgram/520430baeb85384bab46442ef654ec043a4c0b5b/includes%2Fnotifications%2FCourseTalkFormatter.php In a nutshell, when the notification is triggered, the extension *does* send a revid in the 'extras' parameter. Maybe I'm missing something, but the only place I see in core to get to the title of a deleted article from the revid is ApiQueryDeletedrevs. We could call that API using DerivativeRequest, but in addition that API checks for the "deletedhistory" user right, not something a notification should try to hack around. We could also just access the archive table directly, but doing that in a notification formatter would be ugly. As far as I can see, there are two real options: - Implement in core a simple interface for getting the last title of a deleted article from the pageId. (Apologies if it's already there and I didn't see it.) Then add code to Echo for fetching a title object or title text if the page represented by the 'title' parameter has been deleted. - Make Echo store the title text somewhere in the notification, so that it can be retrieved by a formatter if the page has been deleted. These options have different implications with regard to performance and what the user sees if a page is moved. It's true we could implement workarounds, but I think a proper fix is Echo's domain, with changes possibly needed in core depending on the approach.
(In reply to Andrew Green from comment #9) > - Implement in core a simple interface for getting the last title of a > deleted article from the pageId. (Apologies if it's already there and I > didn't see it.) Then add code to Echo for fetching a title object or title > text if the page represented by the 'title' parameter has been deleted. Also note that this may have security ramifications. RevisionDelete allows suppressing log entries (which I believe, but am not positive), includes the deletion log. See https://www.mediawiki.org/wiki/RevisionDelete You should talk to someone familiar with RevisionDelete and oversight to make sure any solution to this does not cause any undesired data leaks.
(In reply to Andrew Green from comment #9) > > We could also just access the archive table directly, but doing that in a > notification formatter would be ugly. The formatter wouldn't need to do it, it would be done by EchoEvent::getTitle() (In reply to Matthew Flaschen from comment #10) > Also note that this may have security ramifications. RevisionDelete allows > suppressing log entries (which I believe, but am not positive), includes the > deletion log. See https://www.mediawiki.org/wiki/RevisionDelete It does. Though what's most common is to just delete the page at a suppression level which doesn't create a delete log entry/ -- I think Echo should just store the page title+namespace along with page id, and fallback upon that if the page no longer exists. We would need to implement something to ensure the page wasn't suppressed, but I don't think that would be super difficult. This would handle deletion and undeletion gracefully as well as the general case of the page was just deleted.
*** Bug 61426 has been marked as a duplicate of this bug. ***
This problem also occurs if the page was deleted, and selected revisions undeleted. If you have admin rights on en.wp, have a look at [1] which is shown in notifications as "Your edit on [No page] has been reverted by Thecounciloflions. [No page]". The page concerned was [[en:Cat Creek]] [1] http://en.wikipedia.org/w/index.php?title=Special:Undelete&target=Cat+Creek×tamp=20140522185355&diff=prev
(In reply to Redrose64 from comment #13) > This problem also occurs if the page was deleted, and selected revisions > undeleted. This is because whenever you delete a page and undelete it the page id changes, which is what Echo stores internally, so it thinks the page no longer exists.
Created attachment 15853 [details] Screenshot of notification in oversighted edit Just noting that this also affects oversighted edits on pages that have not been deleted. It does not appear that any data is leaking, at least not when only the edit summary/edit itself are oversighted, but it is pretty ugly. I'm not sure what would happen if the username is also suppressed.
It would say 'username removed' for deleted/suppressed users. We could just hide the notifications completely in these two cases
*** Bug 70384 has been marked as a duplicate of this bug. ***
