-
-
Notifications
You must be signed in to change notification settings - Fork 268
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
feature: Topic muting #914
base: main
Are you sure you want to change the base?
Conversation
@zulipbot add "PR needs review" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this up 👍. This provisionally looks a great add-on! Leaving some comments inline :)
On manual testing, I observed that the unread count for All_msg changes even for muting topics in a muted stream. This edge case could be handled accordingly. (And potentially later in tests too)
minor: Typo in first commit message: API class
=> API call
def test_toggle_topic_muted_status(self, mocker, model, | ||
stream_dict, | ||
initial_muted_topics, op, | ||
response={'result': 'success'}): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add tests for {result
: error
} too for non-existent topics perhaps?
tests/model/test_model.py
Outdated
model.toggle_topic_muted_status(1, 'Stream 1', 'party') | ||
request = { | ||
'stream': 'Stream 1', | ||
'topic': 'party', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe parameterize topics, so as to handle cases for non-existing topics? (See my above comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made an API call with a non-existing topic in the request but it still returned a 'success' response. I'm not sure why that is the case. Maybe it's an issue in zulip api?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right. I just looked over API events for topic muting and it seems like the response will be succeeded regardless of whether any messages have been sent to the specified topic.
The edge cases for error handling might be:
- muting already muted topic
- unumting an already unmuted topic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a look at this API events for topic muting but it did not mention anything about non-existent topics which you pointed out. I raised an issue regarding the same in the api repo.
The edge cases for error handling might be:
* muting already muted topic * unumting an already unmuted topic
request = {
'stream': stream_name,
'topic': topic_name,
'op': 'remove'
if self.is_muted_topic(stream_id, topic_name)
else 'add'
}
This is the code for initializing the request variable for the api call. Depending on the topic's current state(muted/not muted), 'op' is assigned a value which can toggle the state. So there would'nt be an error case as such!
One thing I could do is rename 'op' in parametrize to 'expected_op'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think renaming is fruitful. As you said, the update event wouldn't be called in the edge cases I mentioned 👍
zulipterminal/core.py
Outdated
currently_muted = self.model.is_muted_topic(button.stream_id, | ||
button.topic_name) | ||
type_of_action = "unmuting" if currently_muted else "muting" | ||
question = urwid.Text(("bold", "Confirm " + type_of_action |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On manual testing, I found the bold
attribute isn't working?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea noticed that now. We don't need it to be bold anyways so i'll leave it as an empty string.
self.stream_id, self.topic_name)] = self.count | ||
self.model.unread_counts['unread_topics'].pop( | ||
(self.stream_id, self.topic_name), None) | ||
self.model.unread_counts['all_msg'] -= self.count |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs an edge case handling. (See my review bullet)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't checked other updates, though I could still reproduce this bug (i.e., subtracting unreads in the case of a muted stream)
README.md
Outdated
### Topic list actions | ||
| Command | Key Combination | | ||
|------------------------------------------------------ | --------------------------------------------- | | ||
| Mute/unmute Topics | <kbd>M</kbd> | | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we use auto-generated hotkeys now, thanks to your work in #926 :)
def keypress(self, size: urwid_Size, key: str) -> Optional[str]: | ||
if is_command_key('TOGGLE_MUTE_TOPIC', key): | ||
self.controller.topic_muting_confirmation_popup(self) | ||
return super().keypress(size, key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add a test for this?
This handles updating muting/unmuting topics in a stream by sending the request to the server with the help of an API call. Tests added.
We make use of the PopUpConfirmation for confirmation if the user wishes to continue performing muting/unmuting action of the displayed topic. The TopicButton's stream_name and topic_name attribute allow us to display the affected stream name and topic name in the view. Tests added.
We register the event_type 'muted_topics' to the event queue on startup, along with a handler method which responds to these events appropriately. Depending on whether the topic is already muted or not, the handler method calls the `mark_muted` or `mark_unmuted`. These two functions will update the data structures which keeps track of message counts in a later commit. Tests added
`model.unread_counts` and button counts are updated based on user action of muting or unmuting. During muting of a topic: * We decrease All_msg count by the unread count of topic. * If there are unread messages in the stream, we decrease its count by the same amount as well. During unmuting of a topic: * If there are unread messages in the stream, we replace 'M' with the correct unread count. * If there are no unread messages, we remove the marked 'M'. Tests to be added for mark_(un)muted.
Handles setting count of `model.unread_counts`. Functions `_set_count_in_model` and `_set_count_in_view` are modified to keep track of unread counts of muted topics when a new message is recieved or an existing message is read. This ensures that the count is in sync when the topic is unmuted later on.
New section 'Topic list actions' created in hotkeys.md. New 'topic_list' category created in keys for mapping keys belonging to topic list actions.
On pressing TOGGLE_MUTE_TOPIC, we now ask for confirmation before performing the action of muting/unmuting topics. Tests added.
@zulipbot add "PR needs review" |
ERROR: Label " PR needs review" does not exist and was thus not added to this pull request. |
@zulipbot add "PR needs review" |
@zulipbot remove "PR awaiting update" |
These commits deal with functionality aspects of this new feature. |
Heads up @mkp6781, we just merged some commits that conflict with the changes your 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 |
I have rebased @sumanthvrao branch for topic muting on to the main. I have modified some of the code and logic to accommodate the changes in data structures and added tests while maintaining the same commit structure as earlier.
In the 4th commit, I am yet to add the tests for the two new functions. I will be working on this soon.
Continues work on #467