Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add moved label for topic/stream changes #1331

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Subhasish-Behera
Copy link
Contributor

@Subhasish-Behera Subhasish-Behera commented Mar 17, 2023

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

@zulipbot zulipbot added the size: XL [Automatic label added by zulipbot] label Mar 17, 2023
@Subhasish-Behera Subhasish-Behera changed the title add moved label for just topic/stream changes add moved label for topic/stream changes Mar 17, 2023
@Sushmey
Copy link
Collaborator

Sushmey commented Mar 19, 2023

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 Subhasish-Behera force-pushed the moved_label_2050 branch 2 times, most recently from 3e1788d to ae029fe Compare March 19, 2023 12:11
@Subhasish-Behera
Copy link
Contributor Author

Subhasish-Behera commented Mar 19, 2023

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.

Copy link
Collaborator

@srdeotarse srdeotarse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

RESOLVED_TOPIC_PREFIX
)
and edit_history_event["prev_topic"][2:]
!= edit_history_event["topic"][2:]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

tests/helper/test_helper.py Outdated Show resolved Hide resolved
zulipterminal/helper.py Outdated Show resolved Hide resolved
zulipterminal/model.py Outdated Show resolved Hide resolved
zulipterminal/ui_tools/messages.py Outdated Show resolved Hide resolved
@Subhasish-Behera Subhasish-Behera force-pushed the moved_label_2050 branch 3 times, most recently from bb107af to c1dc02a Compare March 20, 2023 17:37
Copy link
Collaborator

@neiljp neiljp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

zulipterminal/helper.py Outdated Show resolved Hide resolved
# We know it has a topic edit. Now we need to determine if
# it was a true move or a resolve/unresolve.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

zulipterminal/helper.py Outdated Show resolved Hide resolved
zulipterminal/model.py Outdated Show resolved Hide resolved
zulipterminal/model.py Outdated Show resolved Hide resolved
zulipterminal/ui_tools/messages.py Outdated Show resolved Hide resolved
@neiljp neiljp added area: UI General user interface update PR awaiting update PR has been reviewed & is awaiting update or response to reviewer feedback labels Mar 25, 2023
@zulipbot zulipbot added size: L [Automatic label added by zulipbot] and removed size: XL [Automatic label added by zulipbot] labels Mar 25, 2023
@zulipbot zulipbot added size: XL [Automatic label added by zulipbot] and removed size: L [Automatic label added by zulipbot] labels Mar 25, 2023
@Subhasish-Behera
Copy link
Contributor Author

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

@neiljp
Copy link
Collaborator

neiljp commented Mar 29, 2023

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

@Subhasish-Behera
Copy link
Contributor Author

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

@Subhasish-Behera
Copy link
Contributor Author

@zulipbot add "PR needs review"

Copy link
Collaborator

@mounilKshah mounilKshah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 neiljp removed the PR needs review PR requires feedback to proceed label Jun 14, 2023
Copy link
Collaborator

@neiljp neiljp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Comment on lines +1099 to +1153
"EDITED",
id="message_neither_index_to_edited_messages_or_moved_messages",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +1093 to +1150
case(True, False, 7, "EDITED", id="message_indexed_to_edited_messages"),
case(False, True, 6, "MOVED", id="message_indexed_to_moved_messages"),
case(
False,
False,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

else:
edited_label_size = 0
left_padding = 8
label_text = "EDITED"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +447 to +492
for edit_history_event in msg["edit_history"]:
if "prev_content" in edit_history_event:
content_changed = True
if "prev_stream" in edit_history_event:
stream_changed = True
if "prev_topic" in edit_history_event:
current_topic = edit_history_event["topic"]
old_topic = edit_history_event["prev_topic"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +282 to +321
current_topic: Any = None,
old_topic: Any = None,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +278 to +317
msg_id: int,
index: Index,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

resolved_prefix = RESOLVED_TOPIC_PREFIX + " "
if content_changed or stream_changed:
index["edited_messages"].add(msg_id)
elif old_topic:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +285 to +324
resolve_change = False
resolved_prefix = RESOLVED_TOPIC_PREFIX + " "
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +453 to +492
current_topic = edit_history_event["topic"]
old_topic = edit_history_event["prev_topic"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +309 to +348
else:
index["edited_messages"].add(msg_id)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@neiljp neiljp added this to the Next Release milestone Nov 6, 2023
Subhasish-Behera added 5 commits November 6, 2023 13:16
The function analyse_edit_history is called from index
_messages of helper.py. It decouples the edit/moved label
adding mechanism from index_messages to be used later in
_handle_update_messages_event.Stream/content changes comes
under "edited" while topic editing checks cases related to
resolve/unresolve etc which can go either way of "moved"/"edited".
But moved label is applied to specific cases while rest of the cases
are "edited" using else conditional(expect the resolve_change case).
Instead of EDITED label now urwid.Text takes label_text as argument which can
be "EDITED" and "MOVED".
Uses the analyse_edit_history funciton from helper.py
The parameters passed to analyse_edit_history is slightly
diffrent from earlier as it gets the required values from event
information.
Tests adapted.
It tests the possible scenarios for the function as expressed in the test ids.
Tests the conditions for moved and edited label along wth
UI differences.
Fixes zulip#1253
@neiljp
Copy link
Collaborator

neiljp commented Nov 6, 2023

@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.

@neiljp neiljp changed the title add moved label for topic/stream changes Add moved label for topic/stream changes Nov 6, 2023
@zulipbot
Copy link
Member

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.

@neiljp neiljp added PR completion candidate PR with reviews that may unblock merging and removed PR awaiting update PR has been reviewed & is awaiting update or response to reviewer feedback labels May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: UI General user interface update has conflicts PR completion candidate PR with reviews that may unblock merging size: XL [Automatic label added by zulipbot]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Distinguish EDITED vs MOVED in UI
6 participants