feat: fetch restricted runs and display if unrestricted for redeemable catalog

[pwnage101]

ENT-9360

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.05%. Comparing base (f0d0c7e) to head (4ceef8b).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1155      +/-   ##
==========================================
- Coverage   88.06%   88.05%   -0.01%     
==========================================
  Files         394      394              
  Lines        8343     8381      +38     
  Branches     2010     2019       +9     
==========================================
+ Hits         7347     7380      +33     
- Misses        954      957       +3     
- Partials       42       44       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[brobro10000]

[curious] I am wondering if we can pass courseMetadata directly to parse out the courseRunKey directly in the helper function from availableCourseRuns. That way we wouldn't need to pass a specific courseRunKey.

Also if course metadata could be transformed in the useCourseMetadata hook, that would be ideal.
The reason being that courseMetadata would need to parse restricted runs for every usage of the hook versus abstracting that logic direct direct in useCourseMetadata.

The complexity comes from determining the applicableCatalogUuid downstream. A polarizing solution would be to allow a optional argument into the useCourseMetadata hook to pass in applicableCatalogUuid and if that argument is passed, we can determine whether we display the unrestricted runs. If the argument is not passed, we can probably default on not showing the restricted runs.

[adamstankiewicz]

+1 to this suggestion. I think if we can keep the restrictedRunsAllowed logic encapsulated within the useCourseMetadata hook, that would be preferable to avoid needing to consider restrictedRunsAllowed anywhere that reads

The complexity comes from determining the applicableCatalogUuid downstream.

From the useCourseMetadata hook's perspective, I don't think it necessarily needs to know the applicableCatalogUuid; could it simply allow any restricted run(s) as configured by restrictedRunsAllowed, regardless of an applicable subsidy's catalog? For example, the availableCourseRuns returned by useCourseMetadata today do not guarantee the learner has a subsidy covering each of the course runs; the availableCourseRuns is a list of potentially subsidized, enrollable course runs.

---

If courseMetadata.availableCourseRuns returned all available course runs, including restricted (as configured/exposed via restrictedRunsAllowed), I feel CourseRunCards could still cross-check any restricted runs returned via courseMetadata.availableCourseRuns against the associated catalogs for those restricted runs and the catalogUuid associated with the returned userSubsidyApplicableToCourse, if needed. Something like:

const {
    userSubsidyApplicableToCourse,
    missingUserSubsidyReason,
} = useUserSubsidyApplicableToCourse();
const {
    data: {
      catalogList,
      restrictedRunsAllowed,
    },
  } = useEnterpriseCustomerContainsContent([courseKey]);

const { data: courseMetadata } = useCourseMetadata();

// Exclude configured restricted runs from courseMetadata.availableCourseRuns that are *not* covered by the `userSubsidyApplicableToCourse.catalogUuid`.
const availableCourseRunsWithSubsidizedRestrictedRuns = courseMetadata.availableCourseRuns.filter(r => {
  const restrictedRunsForCourse = restrictedRunsAllowed[r.course];
  if (!restrictedRunsForCourse?.[r.key]) { return true; } // course run is not restricted
  // determine whether applicable subsidy covers (configured) restricted run
  return restrictedRunsForCourse[r.key].includes(userSubsidyApplicableToCourse.catalogUuid);
});

// ...

tl;dr; useCourseMetadata would become responsible for determining which restricted runs (if any) to include in its returned .availableCourseRuns (regardless of an applicable subsidy's catalogUuid); then, code paths like here in CourseRunCards that care about the redeemability of the course runs, could filter the .availableCourseRuns by restricted runs that are contained by the userSubsidyApplicableToCourse.catalogUuid.

---

[thought question] That said, I might also consider the possible implications of rendering a restricted run's CourseRunCard for which the learner has no applicable subsidy; e.g., might we want the course run card for the (configured) restricted run to appear, but with a disabled enroll CTA and message about the lack of applicable subsidy?

[pwnage101]

In today's round of updates, I updated useCourseMetadata() to perform an initial pass at filtering the runs based only on restrictedRunsAllowed, but agnostic of the applicable catalog. I'll be honest, it seemed like the Right Thing to do, but I don't actually think it would have any effect on the resulting behavior.

I am intrigued, however, by Hamzah's polarizing proposal to add an optional argument into the useCourseMetadata() hook to pass in catalogUuid, as that would theoretically help centralize the filtering logic. Why am I getting the sense that this is taboo?

[adamstankiewicz]

I think passing a catalogUuid to use as a filter within useCourseMetadata could work; my biggest concern is just coupling useCourseMetadata to any subsidy-related queries within the hook itself. Passing in the applicable catalogUuid seems reasonable, since it's not composing useUserSubsidyApplicableToCourse within useCourseMetadata directly, which is how I may have (incorrectly) interpreted the above suggestion originally.

[adamstankiewicz]

+1 to this suggestion. I think if we can keep the restrictedRunsAllowed logic encapsulated within the useCourseMetadata hook, that would be preferable to avoid needing to consider restrictedRunsAllowed anywhere that reads

The complexity comes from determining the applicableCatalogUuid downstream.

From the useCourseMetadata hook's perspective, I don't think it necessarily needs to know the applicableCatalogUuid; could it simply allow any restricted run(s) as configured by restrictedRunsAllowed, regardless of an applicable subsidy's catalog? For example, the availableCourseRuns returned by useCourseMetadata today do not guarantee the learner has a subsidy covering each of the course runs; the availableCourseRuns is a list of potentially subsidized, enrollable course runs.

---

If courseMetadata.availableCourseRuns returned all available course runs, including restricted (as configured/exposed via restrictedRunsAllowed), I feel CourseRunCards could still cross-check any restricted runs returned via courseMetadata.availableCourseRuns against the associated catalogs for those restricted runs and the catalogUuid associated with the returned userSubsidyApplicableToCourse, if needed. Something like:

const {
    userSubsidyApplicableToCourse,
    missingUserSubsidyReason,
} = useUserSubsidyApplicableToCourse();
const {
    data: {
      catalogList,
      restrictedRunsAllowed,
    },
  } = useEnterpriseCustomerContainsContent([courseKey]);

const { data: courseMetadata } = useCourseMetadata();

// Exclude configured restricted runs from courseMetadata.availableCourseRuns that are *not* covered by the `userSubsidyApplicableToCourse.catalogUuid`.
const availableCourseRunsWithSubsidizedRestrictedRuns = courseMetadata.availableCourseRuns.filter(r => {
  const restrictedRunsForCourse = restrictedRunsAllowed[r.course];
  if (!restrictedRunsForCourse?.[r.key]) { return true; } // course run is not restricted
  // determine whether applicable subsidy covers (configured) restricted run
  return restrictedRunsForCourse[r.key].includes(userSubsidyApplicableToCourse.catalogUuid);
});

// ...

tl;dr; useCourseMetadata would become responsible for determining which restricted runs (if any) to include in its returned .availableCourseRuns (regardless of an applicable subsidy's catalogUuid); then, code paths like here in CourseRunCards that care about the redeemability of the course runs, could filter the .availableCourseRuns by restricted runs that are contained by the userSubsidyApplicableToCourse.catalogUuid.

---

[thought question] That said, I might also consider the possible implications of rendering a restricted run's CourseRunCard for which the learner has no applicable subsidy; e.g., might we want the course run card for the (configured) restricted run to appear, but with a disabled enroll CTA and message about the lack of applicable subsidy?