Skip to content

Update narrow on topic move #5251

@gnprice

Description

@gnprice

In the web app, when you're looking at some conversation and it gets moved to a different stream, or the topic gets edited (including by resolving/unresolving the topic), the narrow you're looking at gets updated to follow the messages.

We should do the same thing. Currently the lack of this actually gets papered over a bit by #2688 -- if you're just passively reading, then you actually won't realize the topic did get moved. But we should fix that, and then this issue will be more visible.

To do so, we'll add a case in doEventActionSideEffects to respond to these events (actions of type EVENT_UPDATE_MESSAGE) by changing the narrow when appropriate. I'm not sure exactly how to implement changing the narrow; it'll involve reaching into the navigation state, using NavigationService.

To detect when a change is appropriate, the key bit of information is propagate_mode. The web app's behavior (from looking at the logic gated by propagate_mode in static/js/message_events.js) appears to be:

  • If propagate_mode is change_all or change_later, proceed. (If it's change_one, skip the remaining steps.)
  • If the compose box is open pointing to the same stream and topic that the edited message was in, update it to reflect the new topic.
    • … But not the new stream, it looks like? Seems like a bug if so.
    • Also (IIUC) move focus to the stream input; and if the new topic is resolved, warn.
  • If (a) we're narrowed to the stream and topic the edited message was in, and (b) moreover the blue box was on one of the messages affected, then change the narrow to the new stream and topic.

For us there's no blue box, so the behavior isn't going to exactly correspond. But I think the most important thing is to correctly handle the case where the move affected all the messages in the conversation -- that's going to be the most common case, at least in communities where people use topic resolve/unresolve. So one way to handle it would be:

  • If propagate_mode is change_all or change_later, proceed. (If it's change_one, skip the remaining steps.)
  • If we have a ChatScreen open to the topic narrow that the edited message was in, update it to point to the new stream and topic.
    • And if the compose box is open and the new topic is resolved, perhaps warn?
  • If we have a ChatScreen open to the stream narrow containing the edited message, and the topic input had the topic the edited message was in, then:
    • If the message stayed in the same stream, update the compose topic to reflect the edit.
    • If the message changed streams… not sure. This is a relatively uncommon case, and it'd be OK to leave this unresolved and just file an issue for it.

This is P1 because it's part of a server release goal: it's needed for #5202.

This should block on #2688, because if we changed the view and left the messages behind in the old narrow, that'd be worse than the status quo.

Metadata

Metadata

Assignees

Labels

P1 high-priorityserver release goalThings we should try to coordinate with a major Zulip Server release.webapp parityFeatures that exist in the webapp that we need to port to mobile. We aren't aiming for full parity.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions