fix(vcs): update processors via the vcsIntegrationSettings endpoint (YT-77) #130

Merged

David merged 1 commit from fix/YT-77-vcs-processor-mutation-endpoint into main

2026-07-18 20:20:26 +02:00

nrupard commented

2026-07-18 18:21:22 +02:00

Member

Summary

project vcs update / delete / create targeted a processor sub-resource that YouTrack does not expose, 404-ing every mutation. This points them at the one writable endpoint - the vcsIntegrationSettings entity. Fixes YT-77.

Root cause (the endpoint hunt)

The original code's own comments flagged these endpoints as "assumed / undocumented". None were right:

.../plugins/vcsIntegrationSettings/processors/<id> and .../processors -> 404 "No subresource for path processors" (no addressable processor sub-resource, for any method).
POST /api/admin/projects/<id> with a nested plugins body -> 200 but silently no-ops: plugins is read-only on the project entity (only leader / description / ... are writable there).
POST /api/admin/projects/<id>/plugins/vcsIntegrationSettings with {processors:[...]} -> 403, not 404. That distinction is the tell: the path resolves and is permission-checked, so this is the write endpoint.

Change

post_vcs_integration_settings POSTs the full processor set to .../plugins/vcsIntegrationSettings and returns the set YouTrack echoes back (via the fields selector).
create / update / delete re-send the FULL set: untouched processors as typed {id,$type} references (the collection is polymorphic - subtypes of VcsHostingChangesProcessor - so a bare {id} is not enough for YouTrack to route/retain it), the mutated one with its changed fields, a new one with no id. Siblings survive whether YouTrack merges the collection by id or replaces it wholesale.
update / delete verify the outcome and error clearly instead of the old cryptic 404; delete reports plainly if the server kept the processor.
Dropped the dead sub-resource path helper; updated the CLI dry-run strings and the four wiremock tests to the real endpoint.

Testing

just pre-commit green (fmt + clippy -D warnings + build + tests; the create/update/delete unit tests now assert the vcsIntegrationSettings POST body and response shape).
Live against the real instance (processor 258-7, project LC): every wrong endpoint 404s or no-ops; the new endpoint reaches 403 with the current CLI token, confirming the path is correct.

Follow-up (not a code issue)

Completing a write needs a token with project-update / VCS-settings write permission. The current CLI token can list (read) but gets 403 on write. Once a privileged token is in place, yt project vcs update LC 258-7 --path psa-systems/lets-chat should repoint the binding (this also clears the stale LC VCS binding after the lets-chat repo move).

## Summary `project vcs update` / `delete` / `create` targeted a processor sub-resource that YouTrack does not expose, 404-ing every mutation. This points them at the one writable endpoint - the `vcsIntegrationSettings` entity. Fixes YT-77. ## Root cause (the endpoint hunt) The original code's own comments flagged these endpoints as "assumed / undocumented". None were right: - `.../plugins/vcsIntegrationSettings/processors/<id>` and `.../processors` -> 404 "No subresource for path processors" (no addressable processor sub-resource, for any method). - `POST /api/admin/projects/<id>` with a nested `plugins` body -> 200 but silently no-ops: `plugins` is read-only on the project entity (only `leader` / `description` / ... are writable there). - `POST /api/admin/projects/<id>/plugins/vcsIntegrationSettings` with `{processors:[...]}` -> **403, not 404**. That distinction is the tell: the path resolves and is permission-checked, so this is the write endpoint. ## Change - `post_vcs_integration_settings` POSTs the full processor set to `.../plugins/vcsIntegrationSettings` and returns the set YouTrack echoes back (via the `fields` selector). - create / update / delete re-send the FULL set: untouched processors as typed `{id,$type}` references (the collection is polymorphic - subtypes of `VcsHostingChangesProcessor` - so a bare `{id}` is not enough for YouTrack to route/retain it), the mutated one with its changed fields, a new one with no id. Siblings survive whether YouTrack merges the collection by id or replaces it wholesale. - update / delete verify the outcome and error clearly instead of the old cryptic 404; delete reports plainly if the server kept the processor. - Dropped the dead sub-resource path helper; updated the CLI dry-run strings and the four wiremock tests to the real endpoint. ## Testing - `just pre-commit` green (fmt + clippy `-D warnings` + build + tests; the create/update/delete unit tests now assert the `vcsIntegrationSettings` POST body and response shape). - Live against the real instance (processor `258-7`, project `LC`): every wrong endpoint 404s or no-ops; the new endpoint reaches **403** with the current CLI token, confirming the path is correct. ## Follow-up (not a code issue) Completing a write needs a token with project-update / VCS-settings write permission. The current CLI token can `list` (read) but gets 403 on write. Once a privileged token is in place, `yt project vcs update LC 258-7 --path psa-systems/lets-chat` should repoint the binding (this also clears the stale LC VCS binding after the lets-chat repo move).

nrupard added 1 commit

2026-07-18 18:21:22 +02:00

fix(vcs): update processors via the vcsIntegrationSettings endpoint (YT-77)

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

Details

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

Details

30face1a99

`project vcs update` and `delete` targeted `.../plugins/vcsIntegrationSettings/processors[/<id>]`, which YouTrack rejects with 404 "No subresource for path processors": there is no addressable processor sub-resource, and `plugins` is read-only on the project entity (a POST there is silently ignored, so an earlier project-nested attempt no-opped). The one writable path is the settings entity itself: POST /api/admin/projects/<id>/plugins/vcsIntegrationSettings with the processor set in the body. Confirmed live: that endpoint returns 403 for an under-permissioned token (the path resolves and is permission-checked), versus 404 for every other shape.

- `post_vcs_integration_settings` POSTs the full processor set to that endpoint and returns the set YouTrack echoes back.
- create/update/delete re-send the full set: untouched processors as typed `{id,$type}` refs (the collection is polymorphic - GitHub/Gitea/GitLab subtypes - so a bare id is not enough), the mutated one with its changed fields, a new one with no id. Siblings survive whether YouTrack merges the collection by id or replaces it wholesale.
- update/delete verify the result and error clearly instead of the old cryptic 404; delete reports plainly if the server kept the processor.

Requires a token with VCS-settings write permission: a read-only token that can `list` still gets 403 on write.

#YT-77

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>