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

P20-119: Add pre-lockdown parental permission banner #58434

Merged
merged 34 commits into from
May 18, 2024

Conversation

artem-vavilov
Copy link
Contributor

@artem-vavilov artem-vavilov commented May 6, 2024

Summary

The banner will appear for students who are not compliant with the Child Account Policy while the CPA experience is cpa_all_user_lockout_warning.

Note: Use the parameter ?show_parental_permission_banner to force the display of the banner.

Screenshots

Home Page

Course Page

Account Page

Links

@artem-vavilov artem-vavilov requested a review from a team May 6, 2024 23:43
@artem-vavilov artem-vavilov requested a review from a team as a code owner May 6, 2024 23:43
const colorStyles = styles.colors[type];
const colorStyles = color
? {backgroundColor: color, borderColor: color}
: styles.colors[type];
Copy link
Contributor

Choose a reason for hiding this comment

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

Since type is now not required, but either color or type seem to need to exist... and since Notification isn't TypeScript and can't support a discriminated union for its properties... maybe we need to at least raise some error if neither key is given. Or have a default type?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm also wondering if it would be more consistent to add your own type instead of adding the ability to directly manipulate the color so that updating the styling the notifications at-large can be made consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with your point about focusing on consistency. However, I bilieve that creating a custom type for each minor change could lead to a bloated component over time. Directly managing styles might be a more efficient approach, ensuring the component stays streamlined and its purpose remains clear

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep, that makes sense. Leave it as you had it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

};

export const UpdateRequestForm = () => {
const state = {
parentalPermissionRequest: {
parent_email: 'parent@email.com',
requested_at: new Date().toISOString(),
requested_at: Date(),
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems so haphazard to trust the localized string of the date instead of something more consistent. Is this really the way one is supposed to handle dates? I'm sure moment can magically handle anything but it feels so wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll revert this change

Copy link
Contributor

Choose a reason for hiding this comment

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

I appreciate your effort on this. I'm never quite confident about handling date serialization. I normally default to the iso format whenever there is doubt, but I'm still ready to be convinced otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When working with an API, the date must be in ISO format. However, I think this is not as crucial for a storybook example

@artem-vavilov artem-vavilov requested a review from wilkie May 9, 2024 12:24
Copy link
Member

@daynew daynew left a comment

Choose a reason for hiding this comment

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

We should add a "shown" metric for this banner.

Base automatically changed from P20-57/pre-lockdown-parrent-permission-modal to staging May 10, 2024 01:09
@artem-vavilov artem-vavilov requested a review from daynew May 10, 2024 20:14
@@ -80,6 +81,12 @@ function showHomepage() {
}

const announcement = getTeacherAnnouncement(announcementOverride);
const parentalPermissionBanner = homepageData.parentalPermissionBanner && (
<ParentalPermissionBanner
key="parentla-permission-bnner"
Copy link
Contributor

Choose a reason for hiding this comment

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

two subtle typos in the key: parental-permission-banner

const inSection = getScriptData('inSection');

const reportEvent = (eventName, payload = {}) => {
payload.isSection = inSection;
Copy link
Contributor

Choose a reason for hiding this comment

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

is this supposed to be isSection or inSection in the event?

@@ -6,7 +6,8 @@
- scriptOverviewData = {scriptData: @script_data, plcBreadcrumb: @plc_breadcrumb}

- content_for(:head) do
%script{ src: webpack_asset_path('js/scripts/show.js'), data: {scriptoverview: scriptOverviewData.to_json }}
%script{src: webpack_asset_path('js/scripts/show.js'),
data: {scriptoverview: scriptOverviewData.to_json, parental_permission_banner: current_user && parental_permission_banner_data(current_user, request).to_json}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Technically, this sets the field to "null" when there is no banner data... and that does work since it is parsed in show.js. The logic in show.js seems to support this dataset field being actual null or undefined. Could we have the data field not exist in that case?

Copy link
Contributor

@wilkie wilkie left a comment

Choose a reason for hiding this comment

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

Looks great! Some comments about some possible typos and a small nit but other than that looks like some great work as usual. I'm happy to approve when those typos are addressed.

@artem-vavilov artem-vavilov merged commit 4bba372 into staging May 18, 2024
2 checks passed
@artem-vavilov artem-vavilov deleted the P20-119/parental-permission-banner branch May 18, 2024 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants