Create page breaks for long tables

[stephaniesimms]

Implement the following rule for any table (e.g., of plans, templates, guidance, user accounts, etc) that exceeds 10 records. See screenshot of UX wireframe below:

• create a new page with links for sequential ordering: 1, 2, 3 ... Next >, Last >>
• add a "View All" link on lower left. if user clicks link, expand the table to display all records.
• change link to say "View less" when complete list is visible. if user clicks this link, revert back to paginated display.

[briri]

@stephaniesimms and @sjDCC this has been deployed to stage for your review. It is currently only applied to the organisational plans in the 2nd table on the my dashboard page. If all looks good we can open a ticket to add it in for other tables throughout the site.

I think it should start out with pagination by default. Right now it starts out as expanded with a 'View Less' link.

@jollopre the queries being fired in the background (when the full list is displayed) appear to be terribly inefficient (tail the logs when you first load the my dashboard page). We should see if its something we can optimize on our end or something introduced by the way this gem is working

[stephaniesimms]

looks good @jollopre - a few changes:

• desired behavior is to only use pagination if the table exceeds 10 records. so no need to display a "View less" link as in screenshot 1 (below) since there is only one plan.
• if a table does contain > 10 records then the default should be to present it w/pagination. the user can then click "View all" to expand and view the complete table.
• for users w/no Org affiliation (listed as "Other") there should be no Org table on the My Dashboard page (screenshot 2). remove "Other Plans"

[sjDCC]

This sounds good. Agree that it should be paginated by default when over 10 records, with an option to view all. We only want to show the second table when users have an official org affiliation too, not 'other'

I also wanted to check what the conditions are for wider university plans displaying. Is institutional visibility the default or do they only appear when users have chosen to make them public or institutional - and they're over 50% complete etc?

I ask as quite a few show in the second tables which will probably be a surprise to DMPonline users. If we don't have 'private' as the default setting we should probably consult before release.

[briri]

Hey Sarah, it looks like the default was set at the database level when we first added the visibility functionality. Since that time though, we made the default a configurable value so that it can be changed per installation (so you could have a different one for Tuuli for example if needed). I just ran a script that sets all of the 1800+ plans that were defaulted to organisationally visible to privately visible (As they should have been all along) and also submitted a PR, #793, to remove that old database level default.

[stephaniesimms]

@sjDCC raises some more good points. I would say that we want to set the following conditions for plans to appear in the Org plans list:

• user has an Org affiliation (not Other)
• other users at their Org have chosen public or org visibility for a plan(s)
• more than 50% questions for each of these plans are answered

this would be consistent with how we display plans in the public DMPs list and messaging w/in the tool about visibility settings. Public DMPs should include all plans set to public visibility, regardless of Org, with more than 50% questions answered.

[sjDCC]

Great, thanks @briri

[jollopre]

@briri, regarding your comment: "the queries being fired in the background (when the full list is displayed) appear to be terribly inefficient (tail the logs when you first load the my dashboard page). We should see if its something we can optimize on our end or something introduced by the way this gem is working"

It is nothing to do with the gem, it is due to the following lines:

• https://github.com/DMPRoadmap/roadmap/blob/CDL-MVP/app/views/plans/_publicly_visible_org.html.erb#L33
• https://github.com/DMPRoadmap/roadmap/blob/CDL-MVP/app/views/plans/_publicly_visible_org.html.erb#L34

which are hitting the db any time because we are not pre-fetching plan roles neither template phases. Note, this also occurs at displaying user plans (table above) so we should think about something consistent for both views.

[jollopre]

@stephaniesimms, @sjDCC we have a PR to address the pagination consistently, see details at #843. Once it is deployed, you can test the pagination for (my dashboard) as well as for users in super admin area. The implementation for the rest of the pages should be tackled at #815

[sjDCC]

Ok, so can this ticket be closed out then? It seems it's covered elsewhere?

[stephaniesimms]

@sjDCC - we're waiting for deployment so we can test. if things look good on My Dashboard tables, then devs can proceed w/ #815.

[stephaniesimms]

this looks good. just noting here to add search box when standardizing all tables in #815 . closing issue.