Add moved label for topic/stream changes

[Subhasish-Behera]

What does this PR do?

Fixes #1253

Tested?

• Manually
• Existing tests (adapted, if necessary)
• New tests added (for any new behavior)
• Passed linting & tests (each commit)

Commit flow

commit 1:

1. add the moved_message field in class Index
2. Add the logic of when to add message to index["moved_messages"] and index["edited_messages"].

Tried to achieve parity with the logic of Zulip webapp's handling of edits
mainly from the analyse_edit_history function of zulip/static/js/message_list_view.js
(web app's code doesn't use indexing like ZT though)

commit 2:

the second commit focusses on implementing the same logic in case of update_message_event. But in first commit the logic was related to the response values of Message but in this case its with update_message event.
does similar job.

In both of the commits , the code identifies a real topic change vs unresolve/resolve
Notes & Questions

Interactions

[Sushmey]

Thank you for your effort @Subhasish-Behera !
The code looks well written and seems to work like it's supposed to. Are these all the flags that need checking under message update event? Also, tests normally don't need to be mentioned in the commit title/summary.
Other than that everything looks good!

[Subhasish-Behera]

Thank you for your effort @Subhasish-Behera ! The code looks well written and seems to work like it's supposed to. Are these all the flags that need checking under message update event? Also, tests normally don't need to be mentioned in the commit title/summary. Other than that everything looks good!

@Sushmey, Changed the commit messages.
Re message update event. ZT treats update_message_event(content/stream/topic changes at least) almost like it's a message event but with a different response value. I thought that way and came up with the code for update_message_event. I am not solving any other bug/enhancement related to edit_history or update_message_event here i.e This code only applies the MOVED label if in the previous version of these functions EDITED label can be applied to those messages.

[srdeotarse]

Thanks for working on this issue 👍. You have understood the issue and have tried to accommodate all conditions that distinguish MOVED and EDITED messages in ZT.

Just a suggestion that it would be really good if you add comments for conditionals related to (un)resolve topics for better understanding.

[srdeotarse]

I think you have not handled moved message case if message is edited to resolve/unresolve topic with same name.

[neiljp]

@Subhasish-Behera Thanks for looking into this :)

Practically speaking this looks to work OK after a quick test 👍

However, the logic is rather difficult to read in parts, partly due to reuse of long variables, and I'm not sure how much has come from server or web app code.

It also looks like you could potentially implement the update part using similar functionality to the first commit, though that may only be clear once the code is easier to read.

There are effectively 3 changes here (at least), and while the last commit says tests added, it seems like it's only updated some tests to pass. We really need tests for all the new behavior, and the messages code doesn't require any test updates, which suggests we don't have a pre-existing test either.

If you end up extracting the common logic between the two parts that I pointed out, testing that function may simplify testing the other parts.

[neiljp]

If this logic is mirrored from a file in the server, it'd be good to link to it in a comment around here.

[Subhasish-Behera]

Now, the analyse_edit_history is present in https://github.com/zulip/zulip/blob/main/web/src/message_edit_history.js

[neiljp]

Ready to review? If so, please switch the PR labels :)

[Subhasish-Behera]

still working on changing the code to be a single function and its tests.

[Subhasish-Behera]

@zulipbot add "PR needs review"

[mounilKshah]

Thank you for working on this @Subhasish-Behera !

I ran the code on my local machine and it worked as expected. The tests written also seem to cover all the possible cases. I manually tried testing for all the cases and it worked perfectly fine. As for the commit structure, we can discuss it on the ZT stream.

[neiljp]

@Subhasish-Behera I intended to only remove the needs-review label, since this needs a rebase and may have outstanding comments to address, including from Mounil here and in the stream. However, I gave this another look and left some further notes.

It's great to see the test(s) 👍 I've not read all of the main function test cases this time, and that test may become simpler if my comments result in adjustment of eg. the function signature (parameters/return/side-effects).

A point I didn't make in an inline comment, is that limiting the UI from directly accessing the model (index) data is something we should aim for. So we could add a model accessor method which returns the 'edit status' as eg. a string (a limited Literal type, perhaps), with that method being the part that interprets the edited/moved sets - and would be easier to test. We could still test the UI, but it'd be a mapping from a string<->UI, so likely less important.

Keeping that interpretation of the sets in the model may make the way in which the sets are updated, eg. whether the sets are kept disjoint, less important - the UI just gets one of 3 results via the accessor method.

I do think it's important that we resolve the current/old topic issue I mention inline, since currently it's unclear what should happen with multiple topic renames in the message history, at least with the current logic.

[neiljp]

If neither, then why is this text "EDITED"?

[neiljp]

There is no True, True case here. Your code doesn't seem to limit this from occurring (considering indexing and events), and I'm not sure if you expect it to?

If we do care about moved and edited being disjoint sets, then somewhere the code needs amending. However, the logic here doesn't currently care - but we need to define that's the case.

[neiljp]

It seems odd that this is EDITED; I know it was a constant previously and the width determined the visibility, but it seems useful to be explicit now the MOVED case is present.

Maybe set this to ""? If so, since we'd have distinct strings in each case, can the other parameters all be defined in terms of them?

[neiljp]

This piece of code is not tested. I don't have an issue with setting the flags on looping through the history, but the current/old_topic data depends on the order of cycling through the history, so could be set to different values multiple times in the history. The test for analyse_edit_history isn't (yet!) in this same commit for me to easily understand if it would matter; it may also be clearer if we can simplify the logic of that function.

While ideally the index method - and so this code - could be tested, I'd feel more comfortable still without a test, if the logic of the passed-in current/old values was clearer, for example if the precise current/old values don't matter in the analyse function. Otherwise I'd question why we don't need to track/analyse all the previous topic changes.

[neiljp]

Please avoid Any if possible.

I also don't see that you need a default parameter here - you're always passing the current and old topic values, even if they are None?

I also see that both current and old topic must be None or str together, or else the middle conditional breaks. In other similar cases we have an assert at the top of the function to ensure that 'coordinated' values are used correctly by callers. The alternative is to define the parameter as a data structure, where the entire parameter can then be None or multiple values.

[neiljp]

There's a lot of duplicate lines in this method, index[something].add(msg_id), which suggests the design may be simplified.

Rather than passing in these parameters so that we can modify the Index, can we return eg. a string for each case? That means we decouple this from the index, which should simplify the test, in addition to knowing that it doesn't depend on the previous edited/moved state - or anything else in the index, which we can't say right now.

[neiljp]

This also depends upon current_topic being non-None, which as it stands is not guaranteed. In other similar cases we have an assert at the top of the function to ensure that 'coordinated' values are used correctly. The alternative is to define the parameter as a data structure.

[neiljp]

These both only apply to the middle section, so move them there?

[neiljp]

Note that topic and prev_topic were both only added in Zulip 5.0, so we'll need a workaround for this, and any test of this part may need to depend upon the feature level - though note that prev_stream works fine since it just skips it if it is not present.

[neiljp]

What part of the input parameter space does this cover? Should this be an error branch instead?

[neiljp]

@Subhasish-Behera I've just rebased and pushed a version of this with the commit text summary split by a blank line (which you didn't have early on while contributing) and rebased to skip adding the symbol and import it instead - since that was the main conflict.

I suspect this needs a little rework due to other changes - it didn't quite pass check-branch locally. That's partly related to the typing of the update_message event, but also a model test failure seems present now.

If you do have updates locally, then feel free to push over this version, but please do fix conflicts and compare it to the changes I just pushed first.

To get this merged, I'd suggest moving the tests into the commit with the related changes, and leaving the update_message commit at the end since that's the update-during-session extension - and the one that may be failing a test now? Some of my points above were comments, but we should certainly look at the server version dependency, and ensure the tests are clear.

[zulipbot]

Heads up @Subhasish-Behera, we just merged some commits that conflict with the changes you made in this pull request! You can review this repository's recent commits to see where the conflicts occur. Please rebase your feature branch against the upstream/main branch and resolve your pull request's merge conflicts accordingly.