Description
Description
We want to achieve parity with the notification-api. Currently, ENP accepts lower-case strings for enums, like recipient_identifier, where the notification-api does not. This ticket aims to restrict any enum passed into a payload in POST /v2/notifications/sms and /legacy/v2/notifications/sms as only what the enum is: stated as with no case conversions.
Note this will also impact email or any legacy route that includes an enum as a payload property.
- Ticket is understood, and QA has been contacted (if the ticket has a QA label).
Steps to Reproduce
- Post a payload to either of the above mentioned routes which include a
recipient_identifierid_typeas the lowercase version of the enum. - Observe that the route accepts this string when it should not.
Workaround
None.
Impact/Urgency
Medium? High?
Expected Behavior
- When I post a payload to ENP which has an enum, then the enum is only accepted if it exactly matches the enums available (no case conversions).
QA Considerations
- Validate all possible POST payload enums
- include case conversion as a negative test case in the QA suite.
Additional Info & Resources
The base model has strict mode enabled. This was done in error.
Strict Mode - Pydantic
app/legacy/v2/notifications/route_schema.py
class StrictBaseModel(BaseModel):
"""Base model to enforce strict mode."""
model_config = ConfigDict(strict=True)
This base model could be removed, setting any models that use it back to using BaseModel instead.
Any model that has fields with Field(strict=False) would then be updated to get rid of this annotation. This was added to allow more relaxed validation specific fields that would not validate with strict mode. This however resulted in overly relaxed validation, i.e. allowing lower case strings to validate against upper-case enums.
Reverting the base models and getting rid of the override annotations should restore proper validation behavior.