Add project and column info to issue and pull request API responses#37036
Add project and column info to issue and pull request API responses#37036myers wants to merge 7 commits intogo-gitea:mainfrom
Conversation
GiteaBot
added
the
lgtm/need 2
GiteaBot
added
lgtm/blocked
|
Again, it conflicts with Multiple projects: #36784 , unless maintainers agree that we would never support multiple projects |
I don't understand blocking work that adds value because there is another change in the same area. That's why we have git and forges! I'm happy they are adding that feature. I don't have any use for it myself. I would like to see us add missing features like this to the project and they can catch up and add support for these features in their PR, or if they get merged before I do, the other way around. EDIT: after thinking about this for a while: I think you are asking for this api to return a list of projects per issue and this PR would only have 0 or 1 items in that list, and when the other PR lands the api doesn't change. Is that correct? I like that idea, I'm implementing it now, sorry it took me a while. :) |
API clients working with project boards currently need separate calls to discover which project and column an issue belongs to. This adds a `project` field to issue and pull request responses containing the project ID, title, state, and board column placement. The project data is loaded via a LEFT JOIN on project_board when loading issue projects, keeping it to one query. List endpoints batch-load projects for all issues in the result set.
- Change ToAPIProject signature to take column fields directly instead of issue pointer (fixes nil panic risk) - Add canDoerSeeProject permission check using EphemeralCache for batched org permission lookups in list endpoints - Repo-level projects: visible if user can read the repo (already checked by API handler) - Org-level projects: check org visibility + projects unit permission - Add integration test for org project visibility in API responses Co-Authored-By: Claude Opus 4 (claude-opus-4-6)
myers
force-pushed
the
feat/issue-project-meta
branch
from
f6b6233 to
74fdb7e
Compare
Co-Authored-By: Claude Opus 4 (claude-opus-4-6)
Co-Authored-By: Claude Opus 4 (claude-opus-4-6)
Change the issue/PR API response from `project` (singular object) to `projects` (array of objects). Today this array has 0 or 1 entries. When multi-project support lands (go-gitea#36784), the API contract won't need to change. Co-Authored-By: Claude Opus 4 (claude-opus-4-6)
|
@wxiaoguang @bircni Would you mind reviewing this again? |
Let's merge #36784 first? |
5 participants
Fixes #14299
API clients working with project boards currently need separate calls to discover which project and column an issue belongs to. This adds a
projectfield to issue and pull request responses containing the project ID, title, state, and board column placement.The project data is loaded via a LEFT JOIN on project_board when loading issue projects, keeping it to one query. List endpoints batch-load projects for all issues in the result set.
One concern: I followed what labels and milestones did and included most fields from the Project. I don't think we actually should send:
for every issue in a list the api gets. Maybe trim all three down in another PR?
Written with Claude Code and Opus, reviewed by a human.