Repository navigation
Conversation
The view now resolves one channel for the request: it keeps an explicit channel, and treats a body that only supplies a cadence as the email_cadence channel. That value is used for the preference update, the analytics event, and the response. A cadence-only update is rejected with 400 when that notification type's email channel is not editable. When the resolved channel is email_cadence, the response reports the cadence, including when the body also contains a boolean value. Fixes openedx#39221
openedx-webhooks
added
the
open-source-contribution
|
Thanks for the pull request, @mvanhorn! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Submit a signed contributor agreement (CLA)
If you've signed an agreement in the past, you may need to re-sign. Once you've signed the CLA, please allow 1 business day for it to be processed. 🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
This branch has not been deployed
2 participants
Description
A v3 notification-preference update that sends an email cadence and omits the channel returns HTTP 500. Validation accepts the body, then the request fails before the preference is saved. The same cadence update succeeds when the channel is included. The update serializer treats a present email cadence as a substitute for the channel, and the success response already fills the channel in as email_cadence in that case. The code that builds the saved update and the preference-update event still reads the channel key directly, so a cadence-only body raises KeyError before anything is written.
The view now resolves one channel for the request: it keeps an explicit channel, and treats a body that only supplies a cadence as the email_cadence channel. That value is used for the preference update, the analytics event, and the response. A cadence-only update is rejected with 400 when that notification type's email channel is not editable. When the resolved channel is email_cadence, the response reports the cadence, including when the body also contains a boolean value.
Fixes #39221
Supporting information
Not applicable to this change.
Testing instructions
npm testcould not run in this environment for the openedx-platform NotificationPreferencesViewV3 change (jest is not installed).Tests for the openedx-platform NotificationPreferencesViewV3 change live in
openedx/core/djangoapps/notifications/tests/test_views.py.Deadline
"None" if there's no rush, or provide a specific date or event (and reason) if there is one.
Other information
Not applicable to this change.