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

bug #930: added email property check, ensuring the correct response. #1066

Merged

Conversation

dev-rahulbhadoriya
Copy link
Contributor

Closes #930

Added a check for the email field. If the property is missing or not included in the request body, an error 400.23 ( propertyNotFound) will be returned.

{
    "message": "Could not find a property named 'email'",
    "code": 400.23,
    "details": {
        "property": "email"
    }
}

What has been done to verify that this works as intended?

Tested with postman.

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Does this change require updates to the API documentation? If so, please update docs/api.md as part of this PR.

Before submitting this PR, please make sure you have:

  • run make test-full and confirmed all checks still pass OR confirm CircleCI build passes
  • verified that any code from external sources are properly credited in comments or that everything is internally sourced

@matthew-white
Copy link
Member

matthew-white commented Dec 20, 2023

Thanks, @dev-rahulbhadoriya! I have a couple of small suggestions. First, I think we should use Problem.user.missingParameter instead of propertyNotFound. Currently, we only use propertyNotFound when validating the $select OData query parameter, where the Problem means "you specified a property that doesn't exist." In other cases, it's more common that we use missingParameter, which has more of a meaning of "you didn't specify a parameter that we expected."

It'd be great if you could also add a test to test/integration/api/users.js for the new behavior. The test could send a request without email, then assert that the resulting response body has correct values for code and details.

Also, just FYI, the project is going to be quieter for the next couple of weeks. You may find that additional review is delayed until 2024. Thanks again for submitting this PR!

@dev-rahulbhadoriya
Copy link
Contributor Author

@matthew-white , thanks for the suggestions and for reviewing my PR. I have corrected the code and added a test case for it. Kindly check and review it

Copy link
Member

@matthew-white matthew-white left a comment

Choose a reason for hiding this comment

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

Sorry for the long delay on review! This is looking great. I'll go ahead and merge now. Thank you for the PR, @dev-rahulbhadoriya!

@matthew-white matthew-white merged commit fc940ff into getodk:master Jan 29, 2025
6 checks passed
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.

Return better error message when email is not specified
4 participants