Thanks for the API surface expansion and controller/action extraction — this is a big step forward. I found two should-fix issues before this is ready to merge: (1) the ticket update API response currently bypasses visibility, and (2) ticket options still return all users instead of project-visible users.
Thanks for the API surface expansion and controller/action extraction — this is a big step forward. I found two should-fix issues before this is ready to merge: (1) the ticket update API response currently bypasses visibility, and (2) ticket options still return all users instead of project-visible users.
Should fix: this options payload currently returns all users in the system. That bypasses the visible-user scoping added elsewhere in this PR (User::visibleToProject) and leaks unrelated account identities via the create-ticket API. Please scope this query to users who can read the project (and add a focused /ticket-options API test for this behavior).
Should fix: this options payload currently returns all users in the system. That bypasses the visible-user scoping added elsewhere in this PR (`User::visibleToProject`) and leaks unrelated account identities via the create-ticket API. Please scope this query to users who can read the project (and add a focused `/ticket-options` API test for this behavior).
Should fix: show_author is enforced in the ticket detail payload, but this update response always loads/serializes author. A non-admin with write access can send a PATCH (including a no-op update) and recover hidden author data. Please apply the same visibility rule here (omit/null author unless the caller can manage the project) so the setting cannot be bypassed.
Should fix: `show_author` is enforced in the ticket detail payload, but this update response always loads/serializes `author`. A non-admin with write access can send a PATCH (including a no-op update) and recover hidden author data. Please apply the same visibility rule here (omit/null author unless the caller can manage the project) so the setting cannot be bypassed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Koda
Thanks for the API surface expansion and controller/action extraction — this is a big step forward. I found two should-fix issues before this is ready to merge: (1) the ticket update API response currently bypasses visibility, and (2) ticket options still return all users instead of project-visible users.
@@ -0,0 +37,4 @@)->resolve(),'ticketTypes' => TicketTypeResource::collection($project->ticketTypes()->get())->resolve(),'users' => UserResource::collection(User::query()Should fix: this options payload currently returns all users in the system. That bypasses the visible-user scoping added elsewhere in this PR (
User::visibleToProject) and leaks unrelated account identities via the create-ticket API. Please scope this query to users who can read the project (and add a focused/ticket-optionsAPI test for this behavior).@@ -0,0 +125,4 @@return TicketResource::make($ticket->fresh()->load(['assignee','author',Should fix:
show_authoris enforced in the ticket detail payload, but this update response always loads/serializesauthor. A non-admin with write access can send a PATCH (including a no-op update) and recover hidden author data. Please apply the same visibility rule here (omit/null author unless the caller can manage the project) so the setting cannot be bypassed.Here is the improvements PR: OpenSource/KanbanGit#53