Add listable scope attribute for conversations

[PVince81]

Related issue

Fixes #1763

Description

Added ability to set a conversation as listable for regular users and/orguest users from the guest app.
This means those users will be able to search for those rooms and join them even if they haven't joined before.

Todos

• add new conversation property (mostly copy-pasted from read-only)
  • DB migration for new property
  • backend endpoint to set property
  • settings frontend
  • detect guest app in UI => obsolete ?
• search provider impl
  • impl
• implement search results code based on listable flags
  • show listable only in search results, not regular list
  • filter by scope (regular user vs guest)
  • backend endpoint "/listed-room"
  • frontend
• allow joining listable conversations
• unit tests
  • SystemMessageTest
  • SystemMessage/ListenerTest
  • RoomController, Manager, ParticipantService => cover with integration test ?
  • ListedConversationSearch (if we agree to keep it) removed

Issues

• BUG: somehow the dialog always shows "Everyone" by default
• sort out todos in LeftSidebar
  • use ConversationsList ?
  • sort out "no search results" case, currently nothing appears if no results
  • optional: cancel search when continuing to type? => later in Cancel search while typing #4742
• implement recognizing guest users (see FIXMEs and TODOs)

Testing

• verify that cli + defaults there work correctly
• test direct join to private listed room when knowing the URL
• test join via left sidebar
• test join via global search result
• test with guest users from guest app
• test perms
• integration tests (see read-only ones)
  • only moderators can change listable property
  • can join room when knowing URL
    • when listed + private (+ system message visible)
    • when listed + public (+ system message visible)
    • when non-listed + public (+ system message NOT visible)
  • cannot join room when non-listed and private
  • listed rooms of public and private types appear in search results from "/listed-rooms" API, with search term
  • listed rooms of public and private types appear in search results from global search API, with search term => removed

Open topics

• clarify if flags concept was correct, see Public vs private rooms - Allow users to freely join a room #1763 (comment) => adjusted to be a scope, not bitmask any more
• unsure if "all" state is a good idea in regards to extensibility => obsolete
• instead of checkbox, use dropdown for a single-shot choice ? => obsolete
• USER vs USER_SELF_JOINED, see Add listable scope attribute for conversations #4706 (comment)
• add listable field already in creation dialog ?
• review discuss the UX concept as the current idea of listable x public/private is already very confusing
• might need yet another visual indicator in the list to show listed rooms vs non-listed (for moderators to know).
• should we forbid joining listable rooms when calling "/active" endpoint if version used is not v3 ? => no
• password is only asked if not alowed to join a listed room resulting in USER_SELF_JOINED instead of USER, is this ok ?
• should we remove listed conversations from the global search ? => yes, as discussed. they'd cause too much noise there.
• should we force passing in a search term in the "listed-room" API ? or listing all is fine on API level ?

[PVince81]

I've pushed a few more commits which I had locally which make the search result visible in the left sidebar.

I'm not too happy as it uses the global search provider and it feels wrong.

Tomorrow I'll look into the endpoint that lists joined conversations and see if I can extend it somehow.

[nickvergessen]

We once also discussed a dedicated view for them? Having it on the normal endpoint would make integration for the mobile clients pretty easy.

[PVince81]

• make sure that other endpoints also allow retrieving listable rooms by token (like getSingleRoom, etc)

=> maybe not, if the endpoint is "listed-room" then if we need to retrieve a single room it should happen on that endpoint instead (which we can implement later if needed)

[PVince81]

We once also discussed a dedicated view for them? Having it on the normal endpoint would make integration for the mobile clients pretty easy.

yeah, but as a first step we agreed to not handle "guests outside the guest app" for now due to the missing view

[PVince81]

Adjusted after review.

Also modified to use a new endpoint "/listed-room" to search and used the Conversation component to display results.
Regarding the endpoint, I'm not sure how many fields we want / don't want to be populated, I hoped what I picked is enough for now. A lot of values might be null/zero/default as they are not relevant when the user is not a participant (has not joined the room).

Next up: making it possible to actually join those listable rooms

[PVince81]

• might need yet another visual indicator in the list to show listed rooms vs non-listed (for moderators to know).

somehow I dislike the term as it somehow conflicts with "public" vs "non-public". might need to come up with better terms before this is finalized

=> moved to top post

[PVince81]

It is now possible to join listable rooms by clicking on the left sidebar.

Next up: improve the UX after clicking:

• some JS errors appear
• it doesn't directly appear in the list and need to wait for the regular refresh => fetch it earlier + scroll to it

[PVince81]

after a lot of trial and error I managed to make the transition look clean when clicking on a listable entry: the left sidebar will appear with an entry saying "Joining..." until it gets refreshed.

as an added bonus, the left sidebar now scrolls to the item after joining.

still unresolved issues:

• participant not found in "updateSessionId" action
  • because at the time of joining it's not available yet and might need initialization that only happens further down the road.
  • also somehow it seems the lines are swapped, shouldn't we first set the current participant before calling getCurrentParticipant ?
    => solved 2baed21
• sometimes joining seems to hang somewhere and the search result still appears, but the backend has joined already
• missing "you joined conversation" system message -> need to trigger "user_added" event
  • fix and make sure messages only appear when joined as "USER", not "USER_SELF_JOINED"

[nickvergessen]

after a lot of trial and error I managed to make the transition look clean when clicking on a listable entry: the left sidebar will appear with an entry saying "Joining..." until it gets refreshed.

The response of the join should contain all the conversation info iirc?

[PVince81]

@nickvergessen if the POST to "/active" does, then could try and add it to the store right away.

So far I noticed that the conversation is re-fetched later on which automagically makes it work, somehow. (seems it's refreshConversations from the timer)

I still do wonder how non-listable conversations can work correctly in this code path, isn't getParticipantIdentifier() outdated here

spreed/src/services/participantsService.js

Line 56 in 2fc5379

participantIdentifier: store.getters.getParticipantIdentifier(),

? it might have the value from the previous room, unless I misunderstand something in the "join room dance"

[PVince81]

participant not found error solved by adding the conversation early, as discussed: 2baed21

[PVince81]

removed redundant isset, fixed DCO issue, rebased

expecting green now :-)

[nickvergessen]

Version bump got lost on rebase because master already is 11.0.0-dev.9

[PVince81]

as discussed, I've adjusted the listable dropdown width and tested with the dyslexia font:

[backportbot-nextcloud]

The backport to stable20.1 failed. Please do this backport manually.

[backportbot-nextcloud]

The backport to stable20 failed. Please do this backport manually.

[PVince81]

we didn't backport the conversation settings: #4576

unless critical, I'd rather not backport these huge changes

[nickvergessen]

we shouldn't backport this at all...

[PVince81]

ah, seems you asked the bot to backport a single commit about the ctrl+c... not sure why there would be conflict, maybe the bot tried to backport all

I can do this manually

[PVince81]

here we go: #4759

[nickvergessen]

Ah, no the problem is you rebased and the sha of the commit didn't exist anymore.

[PVince81]

this PR will remove the guest manager cheat: #4764