passbolt/passbolt_api · error · ValidationException

Could not validate permission data.

Error message

Could not validate permission data.

What it means

ValidationException thrown by PermissionsCreateService::handlePermissionValidationErrors when a Permission entity built for saving has entity errors after validation. It centralizes the conversion of CakePHP entity validation errors into an API ValidationException carrying the entity and table context.

Solutions

1. Read $exception->getErrors() (entity errors) to see which field failed and correct the payload.
2. Use a valid permission type constant (PermissionsTable::OWNER, EDIT, READ) instead of arbitrary integers.
3. Ensure aco_foreign_key references an existing resource and aro references an existing user/group.
4. Catch ValidationException in the controller to return structured errors to the client.

Example fix

// before
$permission = $permissionsService->createPermission($resourceId, [
    'aro' => 'user', 'aro_foreign_key' => $userId, 'type' => 99,
]);

// after
$type = PermissionsTable::EDITOR; // 7
$permission = $permissionsService->createPermission($resourceId, [
    'aro' => 'user', 'aro_foreign_key' => $userId, 'type' => $type,
]);

// PHP
$validTypes = [PermissionsTable::OWNER, PermissionsTable::EDIT, PermissionsTable::READ];
if (!in_array($data['type'] ?? null, $validTypes, true) || empty($data['aro_foreign_key'])) {
    throw new BadRequestException(__('Invalid permission payload.'));
}

function isValidPermissionPayload(array $row): bool {
    return isset($row['aro'], $row['aro_foreign_key'], $row['type'])
        && is_int($row['type']);
}

try {
    $permission = $service->createPermission($resourceId, $data);
} catch (\App\Error\Exception\ValidationException $e) {
    return $this->respondValidationError($e->getErrors()); // structured field errors
}

When it happens

Trigger: Calling createPermission (e.g. from share operations or permission add endpoints) with permission data failing entity rules — invalid aro/aco type, missing aco_foreign_key, unknown permission type integer, or permission on a non-shareable resource.

Common situations: Clients sending permission.type outside the allowed constants (1/7/15 etc.); sharing with a user/group id that fails validation; API consumers constructing permission payloads manually with wrong field names.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• Could not validate action data.
• Could not validate group data.
• Could not validate permission history data.
• " " is not a valid search filter.
• " " is not a valid search filter. It is not a UTF8 string.

AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17). Data as JSON: /api/errors/c4f2e9521c644cc9. Report an issue: GitHub.

Appendix: source

Thrown at src/Service/Permissions/PermissionsCreateService.php:137

            'created_by' => true,
            'modified_by' => true,
        ];

        return $this->permissionsTable->newEntity($data, ['accessibleFields' => $accessibleFields]);
    }

    /**
     * Handle permission validation errors.
     *
     * @param \App\Model\Entity\Permission $permission The permission
     * @return void
     */
    private function handlePermissionValidationErrors(Permission $permission): void
    {
        $errors = $permission->getErrors();
        if (!empty($errors)) {
            $msg = __('Could not validate permission data.');
            throw new ValidationException($msg, $permission, $this->permissionsTable);
        }
    }
}

View on GitHub (pinned to 31c1bbc10f)