feat(project): add a team group for project access and roles #136

Merged

Claude-Run merged 1 commit from feat/YT-83-project-team into main

2026-08-01 20:41:46 +02:00

Claude-Run commented

2026-08-01 20:40:44 +02:00

Member

yt project covered list / show / states / vcs, and nothing reproduced the Settings > People screen: project show surfaces only the project leader and user list is instance-wide, so "who has access to this project" had no answer from the CLI. YouTrack 2026.1 moved the project-team and role surface out of Hub into the REST API, which makes a single code path possible.

Adds yt project team list/add/remove/grant/revoke. list prints one row per holder (each direct member user, each member group, and the team group itself when it holds a role, which is how a role reaches every member at once) with that holder's project-scoped roles; --all adds the Other People with Access section, and --json emits the whole structure including the team entity and the raw role assignments. add / remove change membership and grant / revoke change project-scoped role assignments, for a user (--user <login>) or a group (--group <name>).

Client work lands in youtrack-client: get_project_team, list_project_team_users, list_project_assigned_roles, add_project_team_member, remove_project_team_member, grant_project_role, revoke_project_role, plus the ProjectTeam, UserGroup, Role, RoleHolder, RoleScope, and AssignedRole models. Every collection reads through its own pageable subresource (team/ownUsers, team/groups, team/users, /api/assignedRoles, /api/groups, /api/roles) because an entity read cannot page its nested collections (users($top:2;id) is rejected as invalid query syntax), so nothing is capped at the server's 42-row default. Membership writes go through POST /api/admin/projects/<id>/team since team/users is GET-only, and re-read the team afterwards so a write the server ignored is reported instead of falsely confirmed. /api/assignedRoles takes no project filter (query=project:<X> is rejected as an unknown field), so assignments are paged and filtered on scope.project.id.

The endpoint shapes were probed against the live 2026.2 instance and are recorded as comments next to each client function, the way the vcsIntegrationSettings functions already are. The four write verbs honour the process-wide --dry-run, and a 403 is reported as the permission the account is missing (Read Project for reads, Update Project for writes) rather than a raw HTTP error.

#YT-83

`yt project` covered list / show / states / vcs, and nothing reproduced the Settings > People screen: `project show` surfaces only the project leader and `user list` is instance-wide, so "who has access to this project" had no answer from the CLI. YouTrack 2026.1 moved the project-team and role surface out of Hub into the REST API, which makes a single code path possible. Adds `yt project team list/add/remove/grant/revoke`. `list` prints one row per holder (each direct member user, each member group, and the team group itself when it holds a role, which is how a role reaches every member at once) with that holder's project-scoped roles; `--all` adds the Other People with Access section, and `--json` emits the whole structure including the team entity and the raw role assignments. `add` / `remove` change membership and `grant` / `revoke` change project-scoped role assignments, for a user (`--user <login>`) or a group (`--group <name>`). Client work lands in `youtrack-client`: `get_project_team`, `list_project_team_users`, `list_project_assigned_roles`, `add_project_team_member`, `remove_project_team_member`, `grant_project_role`, `revoke_project_role`, plus the `ProjectTeam`, `UserGroup`, `Role`, `RoleHolder`, `RoleScope`, and `AssignedRole` models. Every collection reads through its own pageable subresource (`team/ownUsers`, `team/groups`, `team/users`, `/api/assignedRoles`, `/api/groups`, `/api/roles`) because an entity read cannot page its nested collections (`users($top:2;id)` is rejected as invalid query syntax), so nothing is capped at the server's 42-row default. Membership writes go through `POST /api/admin/projects/<id>/team` since `team/users` is GET-only, and re-read the team afterwards so a write the server ignored is reported instead of falsely confirmed. `/api/assignedRoles` takes no project filter (`query=project:<X>` is rejected as an unknown field), so assignments are paged and filtered on `scope.project.id`. The endpoint shapes were probed against the live 2026.2 instance and are recorded as comments next to each client function, the way the vcsIntegrationSettings functions already are. The four write verbs honour the process-wide `--dry-run`, and a 403 is reported as the permission the account is missing (Read Project for reads, Update Project for writes) rather than a raw HTTP error. #YT-83

Claude-Run added 1 commit

2026-08-01 20:40:44 +02:00

feat(project): add a team group for project access and roles

Check / fmt + clippy + build + tests (pull_request) Successful in 51s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

d3b109a6a8

`yt project` covered list / show / states / vcs, and nothing reproduced the Settings > People screen: `project show` surfaces only the project leader and `user list` is instance-wide, so "who has access to this project" had no answer from the CLI. YouTrack 2026.1 moved the project-team and role surface out of Hub into the REST API, which makes a single code path possible.

Adds `yt project team list/add/remove/grant/revoke`. `list` prints one row per holder (each direct member user, each member group, and the team group itself when it holds a role, which is how a role reaches every member at once) with that holder's project-scoped roles; `--all` adds the Other People with Access section, and `--json` emits the whole structure including the team entity and the raw role assignments. `add` / `remove` change membership and `grant` / `revoke` change project-scoped role assignments, for a user (`--user <login>`) or a group (`--group <name>`).

Client work lands in `youtrack-client`: `get_project_team`, `list_project_team_users`, `list_project_assigned_roles`, `add_project_team_member`, `remove_project_team_member`, `grant_project_role`, `revoke_project_role`, plus the `ProjectTeam`, `UserGroup`, `Role`, `RoleHolder`, `RoleScope`, and `AssignedRole` models. Every collection reads through its own pageable subresource (`team/ownUsers`, `team/groups`, `team/users`, `/api/assignedRoles`, `/api/groups`, `/api/roles`) because an entity read cannot page its nested collections (`users($top:2;id)` is rejected as invalid query syntax), so nothing is capped at the server's 42-row default. Membership writes go through `POST /api/admin/projects/<id>/team` since `team/users` is GET-only, and re-read the team afterwards so a write the server ignored is reported instead of falsely confirmed. `/api/assignedRoles` takes no project filter (`query=project:<X>` is rejected as an unknown field), so assignments are paged and filtered on `scope.project.id`.

The endpoint shapes were probed against the live 2026.2 instance and are recorded as comments next to each client function, the way the vcsIntegrationSettings functions already are. The four write verbs honour the process-wide `--dry-run`, and a 403 is reported as the permission the account is missing (Read Project for reads, Update Project for writes) rather than a raw HTTP error.

#YT-83