Home page fixes

[rtibbles]

Summary

• Fixes issue for learner classroom viewset where there were no contentnodes to query, would query all contentnodes
• Show classes section to learners who cannot see unassigned content but who are not in any classes
• Remove the unassigned content guard from the content page route so that learners can access content when they are only allowed to access assigned content
• Fixes an erroneous string reference (that I thought I fixed before?) in the side panel close button
• Fixes a resumable resource check in the backend to check for progress greater than 0 and less than 1

References

Fixes #8729
Fixes #8730
Fixes #8732

Reviewer guidance

If a learner is assigned to a classroom but has no lessons or quizzes, does the homepage still load quickly?
Confirm fixes for the three above.

---

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Critical and brittle code paths are covered by unit tests

PR process

• PR has the correct target branch and milestone
• PR has 'needs review' or 'work-in-progress' label
• If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• If this is an important user-facing change, PR or related issue has a 'changelog' label
• If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[pcenov]

@rtibbles, yes the issues described in #8729 #8730 #8732 are now fixed and the homepage still loads quickly if a learner is assigned to a classroom with no assigned lessons or quizzes.

[MisRob]

I don't understand what the desired effect of this change was. The PR description says

Remove the unassigned content guard from the content page route so that learners can access content when they are only allowed to access assigned content

but removing it will allow learners to access this page no matter their device settings, is that right?

[rtibbles]

Yes - with this guard in place, learners could not access a content page at all. This is a result of the deprecation and removal of the lesson specific content page in favour of TOPICS_CONTENT - I don't know that this was entirely intentional, but that's where we are now, so we need to allow this.

[MisRob]

Thank you. If we allow all learners to access a resource page, what about related pages that still have the guard in place and it's possible to navigate there from this page, for example this route? Does the guard need to be removed from every related page then?

[MisRob]

Wondering if it'd make sense to rather revisit the guard based on new requirements when compared to removing only one of its occurrences to prevent issues that could result from having it for some routes and not having it for others.

[MisRob]

I'm sorry for the invalid route link, not sure what's wrong. I was referencing one route above:

{
    name: PageNames.TOPICS_TOPIC,
    path: '/topics/t/:id/:subtopic?',
    handler: (toRoute, fromRoute) => {
      if (unassignedContentGuard()) {
        return unassignedContentGuard();
      }
      // If navigation is triggered by a custom navigation updating the
      // context query param, do not run the handler
      if (toRoute.params.id === fromRoute.params.id) {
        return;
      }
      showTopicsTopic(store, { id: toRoute.params.id, pageName: toRoute.name });
    },
  },

[rtibbles]

I think this should still be in place - when we are viewing content in the lesson context, and the unassigned content guard is active, we shouldn't be providing links to topics or non-assigned content pages. There's an open issue for this in the context of the completion modal, but I think in all other cases we are avoiding this.

[MisRob]

Thank you, @rtibbles