Page MenuHomePhabricator

Echo notifications should show the page name instead of [No page] if the page was deleted
Closed, ResolvedPublic

Description

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)


Version: unspecified
Severity: major
See Also:

Attached:

Notification.png (38×545 px, 2 KB)

Details

Reference
bz50829

Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:49 AM
bzimport added a project: Notifications.
bzimport set Reference to bz50829.
bzimport added a subscriber: Unknown Object (MLST).

This affects other notifications as well, I've seen it happen to link notifs.

  • 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.

andrew.green.df wrote:

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&timestamp=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.

molly.white5 wrote:

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.

Attached:

Screenshot_from_2014-07-06_19:22:22.png (81×452 px, 5 KB)

bsitu wrote:

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. ***
He7d3r renamed this task from Echo notifications show [No page] instead of pagename if the page was deleted to Echo notifications should show the page name instead of [No page] if the page was deleted.Mar 14 2015, 6:39 PM
He7d3r updated the task description. (Show Details)
He7d3r set Security to None.
He7d3r awarded a token.
He7d3r added a subscriber: He7d3r.
Catrope claimed this task.
Catrope added a subscriber: Catrope.

This was fixed by the notification formatter rewrite in October.