Open verbitan opened 3 months ago
Thank you for your report. Indeed, I would indeed expect the case to be kept during the export.
This might be due to BaseModel.normalize_attribute_name
lowering everything, and PatchOp.value
being of type Any
it does not get reformatted on exports like other Resource
do with that to_camel
serializer..
However, I am not really sure how to fix this. There might be needed to add type parameterss to PatchOp
so it can guess how to correctly case attributes (and also, reject bad attributes by the way?). Something like PatchOp[User]
:thinking:
Another interesting example of this is the following patch request from https://learn.microsoft.com/en-us/entra/identity/app-provisioning/application-provisioning-config-problem-scim-compatibility. In this example, the value keys are lowercased and the .
is removed, so name.givenName
becomes namegivenname
.
PatchOp.model_validate(
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"value": {
"displayName": "Bjfe",
"name.givenName": "Kkom",
"name.familyName": "Unua",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber": "Aklq"
}
}
]
}
).model_dump()
{
"schemas":[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations":[
{
"op":"replace",
"value":{
"displayname":"Bjfe",
"namegivenname":"Kkom",
"namefamilyname":"Unua",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:user:employeenumber":"Aklq"
}
}
]
}
I think a type parameter to PatchOp
is a nice solution, as you can then validate the attributes as part of the model. Though it'd have to handle filters, which complicates things somewhat.
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "emails[type eq \"work\"].value",
"value": "TestMhvaes@test.microsoft.com"
}
]
}
[RFC7644] (Section 3.5.2.3) lists the following example of a valid
urn:ietf:params:scim:api:messages:2.0:PatchOp
object,PatchOp.model_validate()
validates this request as expected, but it lowercases all the keys of the JSON object, meaning they no longer match the schema. I don't believe this to be correct.[RFC7644] (Section 3.10) does make a statement that
All facets (URN, attribute, and sub-attribute name) of the fully encoded attribute name are case insensitive
, and the keys of the JSON object are attributes, which is where I suspect the reasoning of lowercasing all the keys originated, but it's at odds with all other models provided by this library (e.g.User
dumpsuserName
).