Issue module pitfalls

The six behaviors below come down to two habits. Start with these.

Step by step

Safely resolve several issues

1. Go to Tools → Issues and filter for what you want to resolve (Issue list — columns, filters, and cards).
2. Review notes before selecting anything. Open the rows one by one and check the Notes section in the side panel. An issue without notes says No notes.
3. Resolve issues with notes one at a time using Resolve in the open panel. This is the only way to preserve their entries (Handling an issue — the side panel).
4. Select the remaining rows with checkboxes. A bar appears above the table with an N selected counter and two buttons: Resolve and Assign.
5. Click Resolve. There is no confirmation dialog — the operation starts immediately.
6. Do not wait for a message; none will appear. This module shows neither confirmation nor errors for any action. The only way to check is to refresh the list (R with the panel closed) and count the rows.
7. Already resolved issues included in the selection are silently skipped. Fewer rows will change than you selected, with no indication.
8. Check the result: the Notes field for every affected issue now contains one line, Bulk resolved via UI. This English text is added by the system. Anything that was there before is gone.

Check whether a change was really saved

1. Change priority with the stars, the assignee, or the status.
2. Refresh the list. Without refreshing, you do not know what happened: priority and assignment update on screen before the server responds.
3. If the old value returns, the server rejected the change. There is no notification; the rejection appears only in the browser console.
4. Permissions are the most common cause, with a catch: bulk actions require create permission in the Issues module, while individual changes require only write. A role with read and write can resolve an issue individually but will be denied when using bulk actions, without seeing an error: the Assign issues window simply stays open and the list does not change (Module permissions — read, write, and create).

1. Bulk “Resolve” deletes notes

This is the costliest pitfall in the module.

Bulk Resolve writes its own text to the comment field, overwriting everything in it. Operator notes and the record of automatic resolution are permanently lost.

There is no confirmation dialog. If selected issues have notes you want to keep, resolve them individually (Handling an issue — the side panel).

2. Bulk actions do not send notifications

Bulk resolve and bulk assignment bypass notifications. Someone assigned twenty issues at once will not be told about it.

Individual changes send notifications as usual. When assigning work, notify your coworker another way.

3. Bulk actions require create permission

A role with read and write access to the Issues module can resolve issues individually but will be denied bulk actions, which require create permission (Module permissions — read, write, and create).

4. Changes may fail to save without warning

A server rejection, most often due to missing permissions, does not show a message. Priority, assignment, or status may look changed until you refresh.

Refresh the view after important changes.

5. The screen itself is not protected by a permission

Any signed-in user can open /issues. Without the Issues permission, however, they see an empty list with no access-denied message — it looks as if there are no issues.

If someone says “there’s nothing there” while you can see dozens of entries, this is why.

6. An empty screen usually means an active filter

The list opens on unresolved and the empty-state message does not mention this. An empty queue looks just like missing data (Issue list — columns, filters, and cards).

Small details

• Sorting by ID does not work — the server does not accept this field and falls back to sorting by update date.
• Sorting by “assigned” uses the user ID, not their name.
• The Source filter shows only active integrations — issues from a disabled integration cannot be filtered this way.
• Cards ignore filters and include resolved issues.
• Issues cannot be deleted — closed issues remain permanently.