passbolt/passbolt_api · error · NotSupportedException
The operation type ` ` is not supported or invalid
Error message
The operation type `%s` is not supported or invalid
What it means
UserScimResource::patch() only supports SCIM operations of type `add`, `replace`, and `remove`. Any other operation type value in the PATCH request's Operations array falls through to the default branch and raises a NotSupportedException (HTTP 501).
Solutions
- Change the operation `op` value to one of `add`, `replace`, or `remove` (lowercase, per RFC 7644).
- Log the raw PATCH body and verify each entry in the Operations array has a valid op string.
- Update the SCIM client library to one that strictly emits RFC 7644 op values.
- If a new op semantic is needed, implement equivalent behavior with multiple add/replace/remove operations.
Example fix
// before
{"Operations":[{"op":"update","path":"active","value":false}]}
// after
{"Operations":[{"op":"replace","path":"active","value":false}]} Defensive patterns
Strategy: type-guard
Validate before calling
const VALID = ['add','replace','remove'];
ops.forEach(op => { if (!VALID.includes(String(op.op).toLowerCase())) throw new Error('unsupported SCIM op: ' + op.op); }); Type guard
const isSupportedOp = (op) => ['add','replace','remove'].includes(String(op?.op).toLowerCase());
Try / catch
try { await scim.patchUser(id, ops); } catch (e) { if (e.status === 501 || /not supported/i.test(e.message)) { log('unsupported op in payload', ops); } else throw e; } Prevention
- Emit only lowercase RFC 7644 op values: add, replace, remove
- Validate payloads against the SCIM 2.0 schema in tests
- Log raw PATCH bodies in staging to catch client typos
When it happens
Trigger: PATCH /scim/v2/Users/<id> whose operation contains an invalid `op` value such as "update", "delete", "modify", a wrongly-cased value like "Replace", or a malformed operation object where the type could not be parsed into a known type.
Common situations: A hand-written SCIM client uses non-standard op names; an Op value arrives with different casing that the Operation parser doesn't normalize; a new SCIM RFC extension op is sent that passbolt doesn't implement; a proxy rewrites the payload incorrectly.
Related errors
- The PATCH operation is not supported
- Invalid data to create a SCIM Operation
- Invalid data to create a SCIM PATCH REQUEST
- Invalid Resource type
- Invalid schema for SCIM PATCH REQUEST
AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17).
Data as JSON: /api/errors/e1e11474b65f5561.
Report an issue: GitHub.
Appendix: source
Thrown at plugins/PassboltEe/Scim/src/Utility/Resource/UserScimResource.php:672
$userPatchData['profile']['first_name'] = '';
break;
case 'name.familyName':
$userPatchData['profile']['last_name'] = '';
break;
case 'active':
$userPatchData['disabled'] = $this->getDisabledValue(isUserActive: false);
break;
case 'emails':
throw new BadRequestException(
'The email can not be changed',
scimType: ScimException::SCIM_TYPE_MUTABILITY
);
default:
// ignore attributes not used in this application
}
break;
default:
throw new NotSupportedException(
sprintf('The operation type `%s` is not supported or invalid', $operation->getType())
);
}
}
}
$this->updateDatabaseUser($userPatchData, $scimEntryPatchData);
// Set the object properties with the updated information
$this->setFromDatabase($this->userEntity->id);
return $this;
}
/**
* Assert that the user being disabled is not an administrator.
*
* @param array $userPatchData The patch data being applied.
* @return voidView on GitHub (pinned to 31c1bbc10f)