Pager does not respect the URL query parameters

Steps to reproduce

Steps to reproduce:
We've discovered this bug using the LTI interface, but it's likely to manifest in other scenarios as well, since the pager code is used in other places.
1. Create a course in your LMS that contains more than one series.
2. Setup the MH permissions so that the users allowed in the course are allowed in both series (i.e. if the course ID is 12345, then both series should allow read access to the role12345_Learner at least).
3. Make sure that (at least) one of the series contains more than 10 videos, so that the results will take more than one page. (see attached image 1st_page.png).
4. Click "Next" or the page number links to go to a different page.

Actual Results:
The next page shows the videos from both series, not just for the series that was displayed in page one (see 2nd_page.png).

Expected Results:
Only the videos belonging to the series being explored should be displayed.

Workaround (if any):


Former user
November 13, 2014, 2:00 PM

Rubén, this may be my bad. I put in a fix with parameter "seriesId", but I believe the LTI uses parameter "series". If the default Engage player also expects parameter "series" versus "seriesId", then the oc_pager.js needs to be updated to change the references to seriesId to series. Do you want me to submit the fix or are you already doing that?

Rubén Pérez
November 13, 2014, 2:06 PM

This issue happens because the JS code in the file oc_pager.js tries to build a new query string from scratch, but it takes into account only a few possible parameters. Instead, it should process the full query string and deal with the only parameter that is relevant for the paging, "page".

For example, when the series shown in the attachment 1st_page.png is loaded, the iframe URL is:


However the link to the page 2 is:


, leading to the situation shown in attachment 2nd_page.png

Of course, there is another parameter that is relevant for the paging in Matterhorn --the number of items per page. However, the pager seems to ignore this setting and hardcode its value to 10. Fixing this is out of this ticket's scope.

Rubén Pérez
November 13, 2014, 2:08 PM

Hey Karen.

I wrote my previous message without seeing your ticket.

I don't think your fix really affected so much. The real problem here is the strategy used: the code shouldn't try to guess all the possible query parameters that are in the URL, but, instead, check whether the "page" parameter is present or not, and update it accordingly.

I have already a fix for this issue, but thank you for your interest!

Rubén Pérez
November 13, 2014, 2:16 PM


On a second thought, indeed your code used the wrong keyword and that's whats causing this issue. However, the code itself is wrong, as I describe above (I have edited the first comment to add an example).

Again, thanks for your interest. I'm surprised you answered so quick!

Former user
November 13, 2014, 2:35 PM

Thanks for fixing this, Rubén!


Rubén Pérez


Rubén Pérez


Incorrectly Functioning Without Workaround

Tags (folksonomy)


Fix versions

Affects versions