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: validation and error display for due date extensions in the API #36187

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

efortish
Copy link

@efortish efortish commented Jan 28, 2025

Fix validation and error display for due date extensions in the API

Description

This PR addresses the issue where the API did not correctly handle and display error cases where the due_datetime field was empty or incorrectly formatted; also, the API did not correctly handle the student/email field when it does not exist. Additionally, this PR ensures that the error messages returned by the API are clear and relevant to the actual validation error encountered.
This is the fix for this issue

Changes Made

  • Reordered Validation Checks, moved the validation check for the student before the check of due_date to ensure that the student is validated first. This prevents misleading error messages when both fields are invalid.

Consistent Error Handling:

  • Ensured that all validation errors are returned using JsonResponse with a clear error key. This makes the error messages consistent and easier for the frontend to handle.

Detailed Error Message:

  • Added specific error message when due_datetime is empty or incorrectly formatted.
  • Ensure that the error message is correct when the student/email doesnt exist.
  • Ensured that the error message for invalid due_datetime is only returned if the student exist.

Objective

The objective of these changes was to improve the user experience by providing clear and accurate error messages when validation fails. This helps users understand what went wrong and how to correct their input.

Achievements

Improved User Feedback: Users now receive specific error messages for each validation issue, making it easier to correct their input.
Consistent Error Handling: All validation errors are handled consistently, making the API more robust and predictable.
Better Code Organization: The validation checks are now logically ordered, improving the readability and maintainability of the code.

Testing

Tested with various inputs to ensure that the correct error messages are returned for each validation failure.
Verified that the frontend correctly displays the error messages returned by the API.

How to test

In the lms, go to the Extensions section in the instructor dashboard and try different inputs, you can:

  1. Leave all fields blank
  2. Put an invalid student/email and the other fields filled out
  3. Put an invalid student/email and other fields blank or some filled out
  4. Put a valid student/email and other fields blank or some filled out
  5. Put a valid student/email, valid graded subsection, but the due_datetime wrong

Note: Please keep in mind that the input "reason" is not required in the serializer, therefore it doesnt matter whether it is filled out or not

Screencast.from.2025-01-28.11-49-33.webm

Related Issues

PR #35392: https://github.com/openedx/edx-platform/pull/35392/files#diff-2e708ec7862cbe8e9fe138f4cde50b224d98e95f958dfc645b5ab76075035d8dR2994-R3008
Issue #124: Errors are not displayed correctly in extensions tab #124
Issue #422: [Test failure] TC_INSTRUCTOR_8: Errors are not displayed correctly in extensions tab #422

@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Jan 28, 2025
@openedx-webhooks
Copy link

Thanks for the pull request, @efortish!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

  • If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
    • This process (including the steps you'll need to take) is documented here.
  • If it doesn't, simply proceed with the next step.

🔘 Provide context

To 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:

  • Dependencies

    This PR must be merged before / after / at the same time as ...

  • Blockers

    This PR is waiting for OEP-1234 to be accepted.

  • Timeline information

    This PR must be merged by XX date because ...

  • Partner information

    This is for a course on edx.org.

  • Supporting documentation
  • Relevant Open edX discussion forum threads

🔘 Submit a signed contributor agreement (CLA)

⚠️ We ask all contributors to the Open edX project to submit a signed contributor agreement or indicate their institutional affiliation.
Please see the CONTRIBUTING file for more information.

If you've signed an agreement in the past, you may need to re-sign.
See The New Home of the Open edX Codebase for details.

Once you've signed the CLA, please allow 1 business day for it to be processed.
After this time, you can re-run the CLA check by adding a comment below that you have signed it.
If the CLA check continues to fail, you can tag the @openedx/cla-problems team in a comment for further assistance.

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.


Where 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:

  • The size and impact of the changes that it introduces
  • The need for product review
  • Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

@efortish
Copy link
Author

Hello @mariajgrimaldi , could you help me with the review of this PR? I will also refine the issue with some things I found.

Copy link
Contributor

@BryanttV BryanttV left a comment

Choose a reason for hiding this comment

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

Hi @efortish! Thanks for your contribution. I was testing the changes and everything works fine! I only have a few minor comments.

  • Remove the trailing spaces in the function. I recommend using trailing spaces extension in VSCode.
  • Remove the double line break in the function.

As a suggestion, It's possible to add a margin in the error message?

image

@mphilbrick211 mphilbrick211 added the needs test run Author's first PR to this repository, awaiting test authorization from Axim label Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs test run Author's first PR to this repository, awaiting test authorization from Axim open-source-contribution PR author is not from Axim or 2U
Projects
Status: Needs Tests Run or CLA Signed
Development

Successfully merging this pull request may close these issues.

4 participants