fix(queue): Enforce user permissions for queue operations in multiuser mode

[Copilot]

Implementation Plan: Queue Operations User Permission Control

• Understand the issue: Users can cancel/pause/clear each other's jobs
• Review existing user isolation implementation
• Implement backend authorization checks
• Implement frontend authorization checks
• Run linting and security scans
• Add informative access denied error messages for cancel and clear
• Fix access denied messages for all cancel/delete operations
• Fix merge conflict in QueueItemComponent

Summary

Successfully implemented comprehensive authorization controls for queue operations with improved error messages for all access denied scenarios.

Recent Changes (addressing feedback)

Issue: White screen caused by incorrect merge conflict resolution in QueueItemComponent.tsx.

Root cause: The merge commit incorrectly combined two features, creating duplicate variable declarations:

• Duplicate currentUser declaration (lines 36 and 47)
• Duplicate handleToggle definition (lines 35 and 66-70)

Fix: Properly merged both features:

1. Permission to manage items (canManageItem) - prevents users from canceling/retrying each other's queue items
2. Permission to view details (canViewDetails) - prevents users from viewing each other's queue item details

Both features now work together correctly:

• Single currentUser declaration
• Single handleToggle that respects canViewDetails
• canManageItem controls cancel/retry button enable state
• canViewDetails controls detail expansion and cursor

Implementation Details

Backend (Python):

• All queue operations require authentication
• Individual operations verify ownership (403 if unauthorized)
• Batch operations filter by user_id for non-admins
• Admin users have full control (user_id=None bypasses filters)
• Pause/resume processor restricted to admins only

Frontend (TypeScript):

• Cancel/retry buttons disabled for other users' items (canManageItem)
• Queue item details expansion disabled for other users' items (canViewDetails)
• Cancel current button disabled if item owned by another user
• Pause/resume buttons disabled for non-admin users
• All queue operation hooks detect 403 status and show access denied message
• Generic error messages shown for other failure types

Testing

Manual testing recommended:

1. Create non-admin user A and B, plus admin user
2. User A starts generation job
3. User B cannot view details or cancel User A's item (buttons disabled, details not expandable)
4. Verify all cancel/delete operations show proper error messages when accessed via API
5. Admin can view and manage all operations

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[bug]: Users can cancel each other's generation jobs</issue_title>
<issue_description>### Is there an existing issue for this problem?

• I have searched the existing issues

Install method

Invoke's Launcher

Operating system

Linux

GPU vendor

Nvidia (CUDA)

GPU model

No response

GPU VRAM

No response

Version number

6.10.0.dev

Browser

No response

System Information

No response

What happened

When operating in multiuser mode and user A starts a generation job, user B sees the yellow "Add to Queue" button spinning in the Viewer plan, and can cancel user A's job either by clicking on either of the "Cancel Current Item" buttons (one in the Viewer panel; the other in the Left Panel.

What you expected to happen

I expect that when another user's job is executing, the "Cancel Current Item" button will be greyed out, and this functionality will be disabled.

Similarly, the Queue should not let a user cancel, pause or clear another user's job.

The Administrator, on the other hand, should be able to see, cancel, pause and resume all user's jobs, including his own.

How to reproduce the problem

No response

Additional context

No response

Discord username

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [bug]: Users can cancel each other's generation jobs #35

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lstein]

@copilot This works quite well. However, would it be possible to make the error message that appears when B tries to cancel an item or clear the queue more informative? Instead of Problem canceling item and Problem clearing queue, could the error message be changed, in the particular instance of a user access denied error, to Problem Canceling Item: access denied and Problem Clearing Queue: access denied ? Do not apply this error message to other queue-related scenarios.

[Copilot]

@copilot This works quite well. However, would it be possible to make the error message that appears when B tries to cancel an item or clear the queue more informative? Instead of `Problem canceling i...

Done! Enhanced error messages now show "Problem Canceling Item: Access Denied" and "Problem Clearing Queue: Access Denied" when users encounter 403 authorization errors. The error handling checks the HTTP status code and only shows the access denied message for authorization failures - other error types still show the generic message. Commit: b16b5ad

[lstein]

@copilot This is not working completely. The "Problem Clearing Queue: Access Denied" message is showing up as expected. However when I cancel an individual item (using the "Cancel Current Item" button) I still see the old "Problem Canceling Item" message, without the qualification.

[Copilot]

@copilot This is not working completely. The "Problem Clearing Queue: Access Denied" message is showing up as expected. However when I cancel an individual item (using the "Cancel Current Item" button...

Fixed! The issue was that several cancel/delete hooks (useCancelAllExceptCurrentQueueItem, useCancelQueueItemsByDestination, useDeleteQueueItem, useDeleteAllExceptCurrentQueueItem) were missing the 403 error detection logic. All queue operations now consistently show "Problem Canceling Item: Access Denied" when encountering authorization errors. Commit: 7eff0ee

[lstein]

@copilot I'm getting a white screen because of an incorrect merge conflict fix in invokeai/frontend/web/src/features/queue/components/QueueList/QueueItemComponent.tsx. Could you fix this? The area in question affects two issues: 1) Do not allow unprivileged users to cancel each others' queue items; and 2) do not show one user's queue details to another unprivileged user.

[Copilot]

@copilot I'm getting a white screen because of an incorrect merge conflict fix in invokeai/frontend/web/src/features/queue/components/QueueList/QueueItemComponent.tsx. Could you fix this? The area i...

Fixed! The merge conflict had created duplicate variable declarations (currentUser and handleToggle). The file now properly combines both features:

1. canManageItem - prevents unprivileged users from canceling/retrying each other's queue items
2. canViewDetails - prevents unprivileged users from viewing each other's queue item details

The white screen should be resolved. Commit: ceb7fc0

[lstein]

Works as advertised.