Ability to remove chats from the sidebar in Connect

[ghost]

In Connect, I have many chats that were started by other members (most of who disappear after just entering a greeting).
I would like the ability to completely remove chats that I'm no longer interested in keeping.

Maybe:
click on a user to highlight it on the left sidebar of users
click on the 3 dots in the upper right pane
where the user profile appears, have a remove button that can be pressed

I know I can filter on the list of users, but I would also like to completely remove them too.

[citizen428]

Thanks for the issue! We'll take your request into consideration and follow up if we decide to tackle this issue.

To our amazing contributors: please wait until we add a help-wanted label to the issue before starting to work on it.

To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @maestromac or @rhymes or @citizen428 from the DEV team and we will follow up within 3 business days.

For full info on how to contribute, please check out our contributors guide.

[sarthology]

@KatNel20 We have block feature also that you can use for filtering users forever.

[ghost]

I don't necessarily want to block them Sarthak, I just wanted to view a shorter list.

[sarthology]

@nickytonline any thoughts on this.

[narender2031]

@sarthology @nickytonline We can add a new field direct_membership is_archive: false that will act as a check. Here is an example, Once you remove the membership from the sidecar then the value will change to true. You can search for this user. After some time if you want to chat with the archived user, you can search the user and when you send him a message, at this time we will change the is_archive: false.

[citizen428]

@narender2031 Conceptually this seems a bit confusing. From the user's perspective, they are archiving a channel, not their membership and I think maybe our code should reflect this? So maybe the archived flag [1] should go on ChatChannel, as there are other scenarios where we want to archive one, e.g. archiving a channel after an event by an admin.

I'd imagine it like this:

• Once a channel has been archived, no one can post in it anymore.
• Group channels can only be archived by admins.
• Direct channels can be archived by either member. In that case, I'm leaning towards creating a new direct channel, not reopening the old one. We can verify uniqueness with a scope to ensure there can be only one active direct channel between two members.
• We could add a way to resurface archived channels: this way users can archive channels to get them out of their sidebar for now, but come back to them later to look for something if they need to.

There may be edge cases I haven't considered, this was more of a brainstorming without looking at the code too much.

[1] I'd prefer archived as column name since ActiveRecord automatically adds predicate methods for booleans and archived? is more idiomatic in Ruby than is_archive?.

[rhymes]

I wonder if we should split the concept of archived from the concept of closed.

I'm not sure which of the two @KatNel20 meant but I'm leaning towards archived.

For example:

As a user I want to be able to remove a chat from the sidebar, archive it, then be given the chance to unarchive those chats or at least find them through a filter. If any of the two parties starts to send messages again, the channel reappears in the sidebar

which ie essentially the last option made by @citizen428 👍

We could add a way to resurface archived channels: this way users can archive channels to get them out of their sidebar for now, but come back to them later to look for something if they need to.

The difference here is that an archived channel is just an hidden one, not a closed one.

The concept of closing a channel (disallowing members from posting to it) seems to be something only admins should be able to do.

What do you think?

[citizen428]

@rhymes To summarize/clarify:

Archive:

• Can be done by any participant.
• Hides channel from the sidebar.
• The channel is still findable to read old messages.
• The channel can still be posted in.
• Posting unarchives the channel again. I think we should treat this like an email thread, i.e. posting by any member in a direct conversation unarchives, what do you think?

Closed:

• Can be done only by channel admins.
• Does not automatically hide channel from the sidebar (I think users should still archive them themselves if they want to remove them, we should just show they are closed)
• Closed channels can not be posted to anymore.
• The can still be found to read their history.

Does this about sum it up?

[rhymes]

Yes, thank you! That's what I had in mind

[ghost]

I agree

[citizen428]

Maybe @benhalpern can weigh in on the proposal summarized here, then we can move this from "feature request" to "ready for dev".

[michael-tharrington]

I like this idea a lot!

I actually was brainstorming a separate idea for Connect channel archiving in Slack, here's what I had to say:

What do y’all think about adding a feature to retire or lock a Connect channel? This way no one is able to chat in the channel anymore, but folks can still view the convo history.

A little context: a Codeland mod asked if we’re going to close out Codeland channels soon and I said yes, we’re just doing a bit of dev work in Connect first, but it got me thinking dang, it’s kinda sad to close out these channels because they’re a really cool record of Codeland.

I know Arit is working on adding delete functionality to admin/chat_channels which is more important to have. But I spoke briefly with her about this idea just a bit ago because it seems like a cool nice-to-have, even if we can’t do it right away. It is pretty edge-casey.

I wonder if we could house both types of archived channels in the same place. 🤔

In one instance, the user chooses to archive a channel that they just don't want to participate in/get notified about anymore, in the other, we're archiving the channel so that no one else can participate in it.

[cmgorton]

This issue looks like it was never moved to ready for dev. Given our new processes for feature requests should we propose this as a potential RFC? Thoughts @rhymes @citizen428 ?

[citizen428]

@cmgorton Yes, probably.

[rhymes]

Agreed

[cmgorton]

I am going to close this issue since we are moving to deprecate connect.
Deprecating Connect Chat