yasithdev opened a new pull request, #161:
URL: https://github.com/apache/airavata-portals/pull/161

   ## Summary
   Completes the de-Thrift of the **projects** read path — 
`ProjectSerializer.userHasWriteAccess` now uses the gRPC **sharing** facade 
instead of Thrift `request.airavata_client.userHasAccess`. Adds a reusable 
`serializers.user_has_access(request, resource_id, permission)` helper for the 
remaining families.
   
   ## Format confirmed from the backend impl + runtime-validated
   `SharingGrpcService.userHasAccess`: `permission_type` is the 
**ResourcePermissionType enum name** (`WRITE`/`READ`/`MANAGE_SHARING`) — the 
backend adds the gateway prefix internally — and the acting user comes from the 
**authenticated token context** server-side (the `user_id` field is passed for 
the facade signature but ignored). An initial `gatewayId:WRITE` guess was 
rejected (`No enum constant ...ResourcePermissionType`); the corrected call 
`user_has_access(resource_id, 'WRITE')` returns **True** for the owner against 
the live backend.
   
   ## Test plan
   - `manage.py check` — no issues.
   - Runtime: seeded a project via the facade, `sharing.user_has_access(pid, 
'WRITE')` → `True`; cleaned up.
   - The migrated `/api/projects/` returns 200 (empty path validated earlier; 
serializer sub-call now also gRPC).
   
   Note: other serializers' `userHasWriteAccess` (experiments, deployments, 
credentials, GRPs) migrate with their read families; the 
`is_gateway_admin`-based ones need admin derived from the token under 
pure-token auth (separate D5 piece).
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to