Repository navigation
Feature/team member installations - #283
Merged
Merged
Conversation
GET /api/v1/deployments/{hash}/member-access?user_id=... answers
owner/member/viewer/null for the deployment's project, so the User Service
can let a Team project member operate the owner's installation (agent
install, add-app, redeploy). Service token only, like the other
service-to-service routes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012TKZy6f5shPzM9WLdswH6f
A project member deploys as the owner, so the install payload carried only the owner's address and the member who started the deployment never got the report. The payload now carries initiator_email for deploy, deploy with a saved cloud and rollback by a member. It is set by the server only: Payload is read from client-supplied project metadata, so the field is never deserialized. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012TKZy6f5shPzM9WLdswH6f
The deployment report carries the server's SSH key and passwords. A member
who deploys now gets it only when the owner turned on server access for
members: project.members_server_access, off by default, set through
PATCH /project/{id}/server-access (owner only) and shown in /seats.
Without it the report goes to the owner only, as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012TKZy6f5shPzM9WLdswH6f
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a new feature allowing project owners to control whether project members receive server SSH keys and passwords in deployment reports. It adds a new database field and API endpoints to manage this setting, updates the deployment flow to notify the correct user(s), and improves access control and reporting for deployments initiated by project members. Additionally, it introduces a new endpoint for determining a user's role in a deployment and updates authorization rules accordingly.
Project Member Server Access Feature:
members_server_accessboolean column to theprojecttable, with database migrations to support toggling whether project members receive servers' SSH keys and passwords in deployment reports. Includes new functions indb::projectto read and update this setting. [1] [2] [3]/project/:id/server-accessallowing project owners to enable or disable server access for members, with the corresponding handler and form. [1] [2]seatsendpoint and response struct) to include the current value ofmembers_server_accessfor transparency to clients. [1] [2] [3]Deployment Reporting and Initiator Tracking:
initiator_emailfield to deployment forms and payloads, updating the deployment flow to set this field, and ensuring it is only set by the server. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]Deployment Access and Authorization:
/api/v1/deployments/:deployment_hash/member-accessto determine a user's role (owner, member, viewer) for a deployment, intended for use by internal services. Updated Casbin authorization rules to allow anonymous group GET access to this endpoint, and included corresponding up/down migrations. [1] [2] [3] [4]Internal Improvements and Refactoring:
require_stacker_service_authfunction for internal service authentication.These changes collectively improve security, transparency, and flexibility in how deployment reports are handled for project members, and provide supporting APIs for internal and external consumers.