Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: ensure email setting model functions as expected #1136

Merged
merged 1 commit into from
Aug 12, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ import {
EXECUTIVE_EDUCATION_COURSE_MODES,
useEnterpriseCustomer,
} from '../../../../app/data';
import { isCourseEnded, isTodayWithinDateThreshold } from '../../../../../utils/common';
import { isCourseEnded, isDefinedAndNotNull, isTodayWithinDateThreshold } from '../../../../../utils/common';

const messages = defineMessages({
statusBadgeLabelInProgress: {
Expand Down Expand Up @@ -342,7 +342,7 @@ const BaseCourseCard = ({
};

const renderEmailSettingsModal = () => {
if (!hasEmailsEnabled) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue with removing hasEmailsEnabled stuff altogether is that not all course enrollment card types/variants should include the email settings dropdown. For example, assignment cards (AssignedCourseCard) should not expose the "Emails settings" dropdown given the assignment is not yet a legit course enrollment (i.e., learner hasn't accepted their assignment yet), so the user would likely face an error when trying to submit the email settings modal to save their choice.

As is, removing this logic, incorrectly exposes the "Email settings" dropdown item for assignments:

image

When keeping this hasEmailsEnabled logic, it might be falsey for the following reasons:

  1. BaseCourseCard is of type/variant AssignedCourseCard, where hasEmailsEnabled is undefined.
  2. BaseCourseCard is not of type/variant AssignedCourseCard, where hasEmailsEnabled represents the state of the whether the learners's current choice of whether emails are enabled for the course enrollment (i.e., false, true).

The modal previously wasn't opening when a learner has emails disabled for an enrollment because of the (2) case above, whereby false is falsey, fulfilling this condition and thus returning null.

We would only want to short-circuit the rendering of the EmailSettingsModal when hasEmailsEnabled is a legit, defined value (i.e., not undefined/null).

For all BaseCourseCard types/variants, the data is run through the transformCourseEnrollment function, and sets the hasEmailsEnabled property based on the emailsEnabled property for the given course enrollment. If the emailsEnabled property is undefined/null (i.e., when the "course enrollment" here is actually representing an assignment, where email settings is not applicable).

By removing the hasEmailsEnabled stuff altogether, notably within getDropdownMenuItems, the "Email settings" dropdown item is incorrectly exposed for AssignedCourseCard, which would introduce a different bug since the related email settings API would error when called within the modal.

I might suggest keeping all the hasEmailsEnabled stuff but make sure the BaseCourseCard component properly handles hasEmailSettings as undefined/null and false as separate falsey conditions throguhout to mitigate these issues. Consider using the isDefinedAndNotNull helper function (source), e.g.:

const renderEmailSettingsModal = () => {
    if (!isDefinedAndNotNull(hasEmailsEnabled)) {
      return null;
    }
};

if (!isDefinedAndNotNull(hasEmailsEnabled)) {
return null;
}
return (
Expand Down
Loading