Filter conversation list for unread / mentioned conversations only

[DorraJaouad]

☑️ Resolves

• Fixes Frontend - Filter conversation list for unread / mentioned conversations only #9677
• The search box gets expanded when it is focused on to cover the filter button.
• During the textual search operation, no filter can be applied

🖼️ Screenshots

🏚️ Before	🏡 After

Default View

Focused on input or during the textual search

🚧 Tasks

• Visual review
• Code review

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not required
• 📘 API documentation in docs/ has been updated or is not required
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required
• 🔖 Capability is added or not needed

[Antreesy]

PR looks a bit messy now. Please, figure out the problem with Eslint and put the code in order.
And don't hesitate to ask questions!

[Antreesy]

Also tests should be adjusted:
https://github.com/nextcloud/spreed/actions/runs/5176171012/jobs/9324649445?pr=9688#step:7:2218

look through the project to see, how findNcActionButton helper is used in tests, and fix spec.js file
You could run tests locally, see scripts in package.json

[Antreesy]

I reverted some codeline wrapping changes and fixed a couple of things: 2865709
You could cherry-pick this commit and apply, to reduce amount of lines changed.

Also could be done:

• squash commits into one (or two commits: one for new functionality, one for refactoring and moving NewGroupConversation component
• we may get rid of EventBus.$on('new-group-conversation-dialog') and call showModalForItem directly from LeftSidebar (see how it's done in other component):

  spreed/src/components/BreakoutRoomsEditor/SendMessageDialog.vue

  Line 110 in 2858a00

  this.$refs.newMessage.focusInput()

[jancborchardt]

Nice! A detail: The sorting of the action menu entries should be the other way around, cause currently the least important (unread messages) is up top.

Also, could you add a screenshot of how it looks like when you have it filtered by e.g. mentions and the action menu is closed? (Needs to be obvious it is in a non-default state and offer a one-click reset, e.g. by showing a chip "Unread mentions" with an x to reset.)

[jancborchardt]

Ah just saw in the issue it will be showing "is:unread" in the search field so that would answer it. It is quite technical though, but something for a follow-up.

[DorraJaouad]

Nice! A detail: The sorting of the action menu entries should be the other way around, cause currently the least important (unread messages) is up top.

Also, could you add a screenshot of how it looks like when you have it filtered by e.g. mentions and the action menu is closed? (Needs to be obvious it is in a non-default state and offer a one-click reset, e.g. by showing a chip "Unread mentions" with an x to reset.)

Thank you. The filter gets cleared by clicking on the x button from the search box.

[Antreesy]

Ah just saw in the issue it will be showing "is:unread" in the search field so that would answer it.

We asked about it in the comment above, actually. Should the query requests like this be language-independent (like Github uses it), or translated for users?

• is:unread
• t('spreed', 'is:unread')

I'd prefer first option, as we are currently using the string match to check if we need to filter results or just search, and translation in current state could break this feature, but method could be adjusted, it's up to user experience.

[Antreesy]

Apart from couple of comments, look nice and clean
Great job!

[Antreesy]

I think, we could use the shorthand property :show-modal.sync here, like in this commit: 82545ba

But we shoul emit update:show-modal with true/false parameter in that case

[marcoambrosini]

I think it's not very good that we're mixing the creation of a new conversation with the filtering of the conversations. This functionality should be done in a separate filtering button.

| search field | filtering options action button | new conversation action button (in the future could also contain join open conversation action button) |

The search field can expand to the whole width of the line when clicked and the other elements can hide during the search operation

blocking because I think that further design conversation is needed @nextcloud/designers

[DorraJaouad]

The design team suggested adding a divider between filters and other options ( there is a 4th option coming up) in this issue which seems good.

At first thought, I had this idea in mind for the filters. We can put the new conversation action button and the list of open conversations action button together in a drop-down list instead of the '+'

[marcoambrosini]

cc @jancborchardt @nimishavijay @szaimen I think this deserves its own button, also to display active state when filtering is active

[marcoambrosini]

I don't think that the search box should be disabled when a filter is active, why are we doing that? The search box should stay clickable so that the search operation can be initiated immediately without worrying about filters.

[DorraJaouad]

I don't think that the search box should be disabled when a filter is active, why are we doing that? The search box should stay clickable so that the search operation can be initiated immediately without worrying about filters.

For example, the user can type a text in the search box and activates a filter right after. As the text remains there, It will be mistakenly thought that the search text is used to filter out the search output. Vice versa, if the search box remains clickable, the user can try to write a textual filter while the filter is active.

2. the search filter can not be applied together with a textual filter

[nickvergessen]

For example, the user can type a text in the search box and activates a filter right after. As the text remains there, It will be mistakenly thought that the search text is used to filter out the search output. Vice versa, if the search box remains clickable, the user can try to write a textual filter while the filter is active.

I commented this in the beginning as well. It would be cool to to be able to filter and additionally still search. Should be doable?

[DorraJaouad]

Yes, we can still amend it but the whole feature was kinda built on the fact that both textual and new filters cannot be combined together. The search box expansion was added purposely to hide the filters during the search operation. Also, there was a reason behind this separation.

..For the purpose of talk search, I don't think we need filtering of the search results. That would be also a bit misleading because the search results are not only joined conversations, but also not joined ones, for which there 's no read/unread state.
#9688 (comment)

I would change it if you all think it is better to combine them. It was like that in the very beginning.

[marcoambrosini]

the user can type a text in the search box and activates a filter right after

@DorraJaouad this shouldn't be possible because as long as there's a search operation undergoing we are not displaying the filter button.

@nickvergessen As I raised previously I think that mixing filtering and searching functionality would complicate things a lot and I see very little benefit to it.

This is what I would suggest as a first iteration of this:
When a filter is active and the user initiates a search, we should just disregard the filter and return the search results normally. Once the user selects a search results we go back to whatever filtering option the user had previously selected.

Also, we shouldn't forget placing an empty content view if the filtering doesn't return any conversation :)

[nickvergessen]

#9688 (comment) I think that mixing filtering and searching functionality would complicate things a lot and I see very little benefit to it.

Alright, was not aware of this since there were too many comments when I returned and got asked. Also makes a bit of sense, so lets see how that feels naturally.

When a filter is active and the user initiates a search, we should just disregard the filter and return the search results normally. Once the user selects a search results we go back to whatever filtering option the user had previously selected.

Should be easily doable by making the switch block an if-statement with the search as first branch.

---

My final pain point would be that the + button should stay visible when searching. If you can not find the conversation you are looking for, you will have to create it, but for that you (currently) first have to clear the search term, which is rather unexpected (in the past we even had the feature that the current search term was automatically prefilled as room name, but that seems to be broken even on stable27)

---

After this we should get the PR in and then consider doing follow ups, to not drag this PR longer than needed.

[nickvergessen]

Also, we shouldn't forget placing an empty content view if the filtering doesn't return any conversation :)

This is already there

[marcoambrosini]

@nickvergessen how about reintroducing that feature as the last search result + empty content of a search instead of leaving the + button visible?

[nickvergessen]

Then let's move that to a follow up too.

So @DorraJaouad todo:

• Remove disable from the searchbox input field
• replace switch with the if from Filter conversation list for unread / mentioned conversations only #9688 (comment)

[nickvergessen]

I think we need some padding between the button and the input, but otherwise good to go from my side:

[Antreesy]

Works and looks good, visually and by the code
Nothing blocking from my side, what we couldn't done later (but I left some commits to consider as a follow-up)

Sufficient approvals reached

[jancborchardt]

Looks nice! :)

[DorraJaouad]

/backport to stable27