Support topics being moved between streams (events)

[neiljp]

We support events where messages in streams have their subject/topic renamed (ie. moving to a different topic in the same stream), but as per a recent Zulip release we should support the events which indicate messages have been moved between streams. This event is a variant of an existing one we handle; the code is currently in models.py.

Initially it is most important to support the events properly.

Currently we don't have any particular role-specific actions, ie. nothing that depends upon whether a user is an admin/owner (or even a bot, going the other way), but there is nothing stopping this being supported - but without handling events correctly, the outcome will not be visible in ZT.

Which topics can be moved and between which streams depends entirely on the server capability, which is not within the remit of ZT.

@Laanan I created this issue based on your note in the unrelated #745.

[Laanan]

Thanks @neiljp !

I am diving into the code to see if I can figure out how it works. Good documentation and tutorial in developer-documentation.md -- thanks for that. Can you point me to what I should read in: https://zulip.readthedocs.io/en/latest/subsystems/ to get me up to speed on how subjects/topics get renamed? I'll look forward to joining the chat on #zulip-terminal. 😄

[neiljp]

The key thing to follow is the get_events call, and how it dispatches to the different _handle_* methods. The expected values in the events should be documented here https://chat.zulip.org/api/get-events

[Laanan]

Awesome, thanks Neil -- I look forward to seeing how it all works!👍

…

On Tue, Nov 17, 2020 at 11:14 PM Neil Pilgrim ***@***.***> wrote: The key thing to follow is the get_events call, and how it dispatches to the different _handle_* methods. The expected values in the events should be documented here https://chat.zulip.org/api/get-events — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOGDAHTCTXZ2FD7M2XZ3X2DSQNX5TANCNFSM4TV4SDHA> .

-- Matt Hall, D.D.S. (804) 912-4034 matthall.dds@gmail.com

[neiljp]

I should point out that there is an outstanding aspect which is in progress to improve this area slightly based on the last part of #785.

[Ezio-Sarthak]

@neiljp Here are some of my assumptions. Do let me know if I am missing/misleading something:

• As per the documentation, new_stream_id should be the endpoint passed only if there is a message moved to another stream. If multiple messages are moved, message_ids are returned with ids of messages to be moved.
• The areas that would require update are: topic narrow, stream narrow, all messages view.
• The logic in PR Refresh topic list view on update message events #785 should be a good serving tool for required event handlings!

That said, I'm interested to work if @Laanan isn't working right now :)

[Laanan]

Hi Sarthak and Niel, I am currently up to my eyeballs in work, so please, by all means, Sarthak, if you would get to this fix, that would be so awesome. I have a few more tweaks to make on a snooze function for Zulip (a bot called snoozebot), and I am about to try out using Gmail's schedule send functionality to schedule send Zulips. These are future integrations/functions I would like to implement directly in Zulip, but, for now, these work arounds should suffice. Thanks!

…

On Fri, Jan 8, 2021 at 10:28 AM Sarthak Garg ***@***.***> wrote: @neiljp <https://github.com/neiljp> Here are some of my assumptions. Do let me know if I am missing/misleading something: - As per the documentation, new_stream_id should be the endpoint passed only if there is a message moved to another stream. If multiple messages are moved, message_ids are returned with ids of messages to be moved. - The areas that would require update are: topic narrow, stream narrow, all messages view. - The logic in PR #745 <#745> should be a good serving tool for required event handlings! That said, I'm interested to work if @Laanan <https://github.com/Laanan> isn't working right now :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOGDAHQIWNS6ZDMTX2G5H6LSY5FFXANCNFSM4TV4SDHA> .

-- Matt Hall, D.D.S. (804) 912-4034 matthall.dds@gmail.com

[Ezio-Sarthak]

That seems to be a cool integration!

Thanks for letting us know about the current status 👍 I'll dig into it after an affirmation from @neiljp :)

[neiljp]

@Ezio-Sarthak Did you mean #745 or #785? (the latter is merged fully now.) Regarding what's necessary, there are likely quite a few areas to update in the UI, including eg. the topic list, if it's open, and it may be easier to see a PR. I'd definitely want to see a PR handling the events cleanly first, and we can consider any topic-moving from the ZT UI later (particularly given it's an admin action). I've not checked, but we may need to check based on server feature-level, or otherwise handle event content carefully.

[Ezio-Sarthak]

Oops, it was a typo there (edited that comment). I meant #785.

Re event handling, I've started mocking some of the code in the merged PR #785, thinking of opening a WIP PR soon :)

[neiljp]

I just clarified that this is the user-visible feature, ie. when receiving events triggered by other users updating topics.

I've split the UI aspect of this into #983, which is the admin-requiring feature.