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

Support (un)resolving topics #1544

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

Conversation

rsashank
Copy link
Member

@rsashank rsashank commented Sep 5, 2024

What does this PR do, and why?

This PR adds support for (un)resolving topics in ZT via TopicInfoView popup menu when topic is highlighted in left_stream_bar and i key is pressed to toggle topic settings.

Changes with respect to completion candidate PR:

External discussion & connections

How did you test this?

  • Manually - Behavioral changes
  • Manually - Visual changes
  • Adapting existing automated tests
  • Adding automated tests for new behavior (or missing tests)
  • Existing automated tests should already cover this (only a refactor of tested code)

Self-review checklist for each commit

  • It is a minimal coherent idea
  • It has a commit summary following the documented style (title & body)
  • It has a commit summary describing the motivation and reasoning for the change
  • It individually passes linting and tests
  • It contains test additions for any new behavior
  • It flows clearly from a previous branch commit, and/or prepares for the next commit

Visual changes

image image

@zulipbot zulipbot added the size: XL [Automatic label added by zulipbot] label Sep 5, 2024
@rsashank rsashank force-pushed the un-resolve-topics branch 2 times, most recently from 6e7c245 to fb82ade Compare September 5, 2024 23:21
rsashank and others added 6 commits September 6, 2024 05:00
The function calls get_latest_message_in_topic to fetch recent message
in topic to be (un)resolved. It verifies user and editing conditions
using can_user_edit_topic function and finally add or remove
RESOLVED_TOPIC_PREFIX from topic name.

Fixes zulip#1075.

Co-authored-by: Shivam Deotarse <[email protected]>
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.

@rsashank Thanks for the followup 👍

I may have had a few more thoughts, but wanted to get these comments to you before I go to bed :)

Re co-authoring, please note that

  • Shivam's email doesn't appear to match his original commits
  • some commits look entirely to be his with no additions; can you cherry-pick those from the original PR instead to indicate that?

Comment on lines +714 to +720
if self.can_user_edit_topic():
latest_msg = self.get_latest_message_in_topic(stream_id, topic_name)
if latest_msg:
time_since_msg_sent = time.time() - latest_msg["timestamp"]
# ZFL < 11, community_topic_editing_limit_seconds
# was hardcoded as int value in secs eg. 86400s (1 day) or None
if 11 <= self.server_feature_level < 162:
Copy link
Collaborator

Choose a reason for hiding this comment

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

To reduce the level of nesting here, consider the matching else blocks for these early conditionals - they're basically error conditions (and we're not handling them, right now!)

In these cases, exiting early after performing those checks means the rest of the function knows it's in a good state and can continue. In terms of indenting, the current indented sections can then become an 'else' but at a non-indented level. (The absence of error handling then becomes fairly obvious too!)

Comment on lines +724 to +730
# ZFL >= 162, realm_move_messages_within_stream_limit_seconds was
# introduced in place of realm_community_topic_editing_limit_seconds
elif self.server_feature_level >= 162:
edit_time_limit = self.initial_data.get(
"realm_move_messages_within_stream_limit_seconds", None
)
else:
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is the new section, and the matching new test case, compared to the previous PR?

Comment on lines +1467 to +1472
initial_data[
"realm_community_topic_editing_limit_seconds"
] = topic_editing_limit_seconds
initial_data[
"realm_move_messages_within_stream_limit_seconds"
] = move_messages_within_stream_limit_seconds
Copy link
Collaborator

Choose a reason for hiding this comment

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

Strictly this doesn't cover the ZFL 183+ (Zulip 7) situation, where the first of these parameters was removed?

We could treat the two parameters as a patch to initial data via a dict, but unfortunately that then leaves assumptions as to whether the two values are in initial_data, ie. for later versions we strictly want to remove the field.

Comment on lines +718 to +719
# ZFL < 11, community_topic_editing_limit_seconds
# was hardcoded as int value in secs eg. 86400s (1 day) or None
Copy link
Collaborator

Choose a reason for hiding this comment

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

This comment seems a little out of position relative to the code? I'd consider reordering the conditional to start with the new maximum, and leave the <11 case to the end with this comment?

Comment on lines +1476 to +1479
model.get_latest_message_in_topic = mocker.Mock(
return_value={
"subject": topic_name,
"timestamp": timestamp,
Copy link
Collaborator

Choose a reason for hiding this comment

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

This suggests the timestamp in the test should be a latest_message_timestamp, to make the field clearer?

The subject/topic is for the entire topic already, so that's clear enough.

)

if self.topic_name.startswith(RESOLVED_TOPIC_PREFIX):
self.resolve_topic_setting_btn_lbl = "Unresolve Topic"
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know this was from the previous PR, but let's use button_label in the expanded form.

Comment on lines +1642 to +1650
def test_toggle_resolve_status(self) -> None:
resolve_button = self.topic_info_view.widgets[-1]
resolve_button._emit("click")

self.controller.model.toggle_topic_resolve_status.assert_called_once_with(
stream_id=self.stream_id, topic_name=self.topic
)

self.controller.exit_popup.assert_called_once()
Copy link
Collaborator

Choose a reason for hiding this comment

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

It looks like you added this extra test, and the one above this?

I'm not sure about using _emit here, at least compared to our normal use of keypress, but that should be fine - what inspired _emit?

@@ -312,6 +312,11 @@ class KeyBinding(TypedDict):
'help_text': 'Show/hide stream information & modify settings',
'key_category': 'stream_list',
},
'TOPIC_INFO': {
'keys': ['i'],
'help_text': 'Show/hide topic information & modify settings',
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is only useful for this feature right now, so perhaps we should update this slightly to mention updating the resolve status.

@@ -467,6 +472,7 @@ class KeyBinding(TypedDict):
"msg_actions": "Message actions",
"stream_list": "Stream list actions",
"user_list": "User list actions",
"topic_actions": "Topic actions",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Topic list actions?

)

self.widgets.append(resolve_topic_setting)
super().__init__(controller, self.widgets, "TOPIC_INFO", popup_width, title)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This TOPIC_INFO has no meaning here yet. Not sure of the ordering; let's leave it for now.

@neiljp neiljp added PR awaiting update PR has been reviewed & is awaiting update or response to reviewer feedback version parity: 5 labels Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR awaiting update PR has been reviewed & is awaiting update or response to reviewer feedback size: XL [Automatic label added by zulipbot] version parity: 5
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support (un)resolving topics
3 participants