Echo notifications show [No page] instead of pagename if the page was deleted
OpenPublic

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:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58234
https://bugzilla.wikimedia.org/show_bug.cgi?id=62435
https://bugzilla.wikimedia.org/show_bug.cgi?id=71534

Attached:

bzimport added a project: Echo.Via ConduitNov 22 2014, 1:49 AM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz50829.
Patrick87 created this task.Via LegacyJul 5 2013, 7:53 PM
matmarex added a comment.Via ConduitAug 26 2013, 11:46 PM

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

Spage added a comment.Via ConduitSep 23 2013, 8:44 PM

Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/223

Quiddity added a comment.Via ConduitOct 6 2013, 6:16 PM
  • Bug 54525 has been marked as a duplicate of this bug. ***
Legoktm added a comment.Via ConduitDec 20 2013, 10:05 PM
  • Bug 58759 has been marked as a duplicate of this bug. ***
tomasz added a comment.Via ConduitJan 26 2014, 2:11 PM

Changing priority to normal, lowering severity to normal since that's not that annoying a bug (though I've just experienced it).

MZMcBride added a comment.Via ConduitFeb 2 2014, 8:04 PM

I just noticed this on the English Wikipedia ("Salinger (film) was linked from [No page].").

jayvdb added a comment.Via ConduitFeb 3 2014, 4:29 AM

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

Ragesoss added a comment.Via ConduitFeb 14 2014, 2:42 AM

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.

bzimport added a comment.Via ConduitFeb 14 2014, 7:38 AM

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.

Mattflaschen added a comment.Via ConduitFeb 14 2014, 6:45 PM

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

Legoktm added a comment.Via ConduitFeb 14 2014, 7:45 PM

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

Legoktm added a comment.Via ConduitFeb 15 2014, 10:03 PM
  • Bug 61426 has been marked as a duplicate of this bug. ***
Redrose64 added a comment.Via ConduitMay 22 2014, 8:29 PM

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

Legoktm added a comment.Via ConduitMay 22 2014, 8:35 PM

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

bzimport added a comment.Via ConduitJul 6 2014, 11:26 PM

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:

bzimport added a comment.Via ConduitJul 24 2014, 5:48 PM

bsitu wrote:

It would say 'username removed' for deleted/suppressed users. We could just hide the notifications completely in these two cases

Legoktm added a comment.Via ConduitSep 4 2014, 7:11 AM
  • Bug 70384 has been marked as a duplicate of this bug. ***
werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:14 PM
Ricordisamoa added a subscriber: Ricordisamoa.Via WebJan 21 2015, 2:07 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.