Add unread list filter for conversations

[Gumbraise]

This pull request adds support for filtering conversations by unread status across several endpoints. It introduces an unread_only query parameter that, when set, restricts results to only those conversations with unread messages for the user. The changes propagate this filter through the handler, manager, and query layers, and include a new SQL condition and tests to ensure correctness.

Unread conversations filter support:

• Added an unread_only query parameter to the handleGetAllConversations, handleGetAssignedConversations, and handleGetUnassignedConversations handlers, passing it through to the conversation manager methods. [1] [2] [3]
• Updated GetAllConversationsList, GetAssignedConversationsList, and GetUnassignedConversationsList in conversation.go to accept and forward the unreadOnly parameter, ensuring the filter is applied throughout the call chain. [1] [2]

Query logic and SQL changes:

• Introduced the unreadConversationCondition SQL fragment, which checks for the existence of messages newer than the user's last seen timestamp and excludes continuity emails. This condition is appended to the query when the unreadOnly filter is active. [1] [2] [3]

Testing:

• Added unit tests in conversation_query_test.go to verify that the unread filter is correctly included or omitted in the generated SQL query based on the unreadOnly parameter.

[abhinavxd]

Hey thanks for the PRs,

I will check these over the weekend

[abhinavxd]

Hey I am gearing up for the next release 2.3.0 this weekend which adds support for inline images, bulk actions and bunch for performance improvements to reduce CPU and ram usage.

I will check this after that. Thanks!

[abhinavxd]

Thanks for the PR! Can you share the use case you had in mind? Want to make sure I'm not missing something.

The general flow from what I've seen with over 100-150 people using libredesk-

An agent replies and sets a status like Replied / Processing, and when the customer writes back the conversation auto-reopens to Open. So agents find what needs attention via status, which updates automatically. An unread filter overlaps almost entirely with that,

so I'm not able to understand the intent of having it as well.

[Gumbraise]

Hey, thanks for your reply!

Yes I understand your point. I agree that statuses like Open / Replied / Processing are the main workflow indicators and I don't see the unread filter as a replacement for that.

The way I see it is more of a user read state, while the conversation status is a global workflow state.

For example: a conversation can be Open but already read by the current agent, or it can be reopened automatically after a customer reply, but the agent may still want a quick way to see only the conversations they personally haven't checked yet.

So the intent is not to overlap with statuses but to add a lightweight inbox filter on top of the existing workflow.

If you think the naming or placement could be improved I would be happy to adjust it.