Page MenuHomePhabricator

Give the user the number of history items they asked for
Open, NormalPublic

Description

Since we're filtering the history, the user doesn't actually get the number they asked for (50, 100, etc.). This isn't the end of the world; if they click through the 'next' links they will see everything they're intended to see, but it's still wrong.

This can be fixed by letting HistoryPager do the re-querying as needed.

See also T108289: Contributions apparently could have wrong pagination, which should probably be fixed similarly but in ContributionsQuery (since ContribsPager is in core).

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 7 2015, 7:43 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Catrope triaged this task as Normal priority.Aug 12 2015, 11:55 PM
Catrope added a subscriber: Catrope.

Change 245621 had a related patch set uploaded (by Mattflaschen):
WIP: Fix history pagination and give user the number of entries they requested

https://gerrit.wikimedia.org/r/245621

Change 245621 merged by jenkins-bot:
Fix history pagination and give user the number of entries they requested

https://gerrit.wikimedia.org/r/245621

Checked in betalabs.

I thought that the fix should apply to the case when a non-admin user requests 20 items per page will get only one due to filtering of suppressed?

vs Admin user requesting and getting 20 items:

Yeah, for some reason this isn't working properly (anymore?) for this case.

E.g. http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:ET10&limit=20&action=history only shows 8 currently. There are well more than 20 the user has permission to see.