-
-
Notifications
You must be signed in to change notification settings - Fork 251
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
bugfix/migration: Support API migration for muted topics #744
Conversation
Logged #745 to track related improvements. |
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.
@preetmishra Thanks for taking this up - other than the bugfix, this has the potential to allow extra details be listed about the muting 👍
While I'm not averse to introducing another data-structure in the Model, if it's necessary I would prefer it be marked private (leading underscore) and access wrapped in a method - particularly since it's use seems to be one particular check that is essentially being duplicated in multiple locations.
A nice extension to this would be supporting events to update these data-structures from the server, and of course potentially a UI to interact locally (you have some of these in #745 👍).
e8f08f3
to
cf22b40
Compare
cf22b40
to
b5feeb7
Compare
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.
@preetmishra Thanks for continuing to work on this; the new adjustments to allow testing against multiple versions may be the element making this more difficult to test.
The last commit is actually also a bugfix, right?
tests/ui/test_utils.py
Outdated
model.is_in_muted_topics = mocker.Mock(return_value=( | ||
[model.stream_dict[msg['stream_id']]['name'], | ||
msg.get('subject', '')] in muted_topics | ||
)) |
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 seems strange since it's basically reimplementing the function?
zulipterminal/model.py
Outdated
# NOTE: The expected response has been upgraded from | ||
# [stream_name, topic] to [stream_name, topic, date_muted] in | ||
# 3.0, Feature level 1. |
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.
It'd be useful to standardize our notes in the code for this; we could add that to the development section - this would make it easier to check for changes at different server versions and feature levels :)
@neiljp The first two commits make modification in the existing code to facilitate the migration. The last commit is the migration commit (should we call it a bugfix?). Note that the first two commits do not introduce any 'new' feature. |
b5feeb7
to
38d90a7
Compare
@neiljp Thanks for the review. In the latest update, I have simplified the parameterize blocks to avoid unnecessary mocking wherever feasible, made |
38d90a7
to
5aace3b
Compare
(Updated to rebase onto upstream/master.) |
This decouples stream muting from is_muted_topic to allow independent muted_topics lookups. Additionally, this adds a docstring to clarify the method further. The method had been here for a while without any use-case. Besides, the current behaviour can easily be achieved by using is_muted_topic with is_muted_stream at any point. Test amended.
5aace3b
to
95e5310
Compare
Updated to resolve conflicts. |
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.
@preetmishra It's good to see this simplification and needed update (bugfix!) - other than also simplifying the code, it should allow simplifying the tests too :)
tests/ui/test_ui_tools.py
Outdated
], ids=[ | ||
# Assuming 'Django', 'topic1' is muted via muted_topics. |
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.
Is this information actually used in this test now? This may not belong in this commit and the test name isn't that clear, but isn't this test focused on ensuring mark_muted
is called if topics are muted in the model?
Other tests may also be simplified in a similar way after this, potentially.
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.
Yes, it is needed here to understand why the values are set to True
/False
for is_muted_topic_return_value
. Though, I have added an additional refactor commit to simplify it.
The is_muted
util test is simplified in this commit itself. We might want to discuss test_classify_unread_counts
- how would we like it to be handled? Maybe as a separate issue.
tests/conftest.py
Outdated
'server_feature_level:None', | ||
] | ||
) | ||
def muted_topics_dict(request): |
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 is the parametrization of muted_topics in the Model only - we should likely have one for initial data from server, and a test for initial data -> model data, which we don't have? (that was in the previous iteration?)
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 didn't have that test in the previous iteration. Thanks for pointing that out.
I have added the test in the latest update with a local parametrize
block in Model.py
. It wouldn't be needed in conftest
as we'd only test against processed_muted_topics
everywhere else.
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'm actually thinking we might move the server response fixtures into a separate fixture file specific to the model in a similar way. What do you think?
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.
The ones that are already in conftest.py
or also the ones that are used in test_model.py
?
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.
In any case, I believe it is reasonable.
Tests amended with simplified parametrize blocks wherever feasible.
This reflects the expected server response change for muted_topics, from [stream_name, topic] to [stream_name, topic, date_muted] in Zulip version 3.0, Feature level 1 (see zulip/zulip@9340cd1). Test updated along with the addition of processed_muted_topics() fixture in conftest.py and added for muted topic's local conversion.
This simplifies the test parametrization and its body.
95e5310
to
9989b91
Compare
@neiljp Thanks for the review. This is ready with improved assertion against server response, improved tests, an additional refactor commit and other in-line suggestions that you mentioned. |
Heads up @preetmishra, 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 |
@preetmishra Thanks for this bugfix and compatibility change (as well as the refactors) 👍 As per PMs I've merged the first four 🎉 I think we can save the last commit for a separate set of changes to review separately. Other than unblocking the other PR, this also could be followed by:
|
This reflects the expected response change for muted_topics, from
[stream_name, topic]
to[stream_name, topic, date_muted]
in Zulip version 3.0, Feature level 1 (see zulip/zulip@9340cd1).Tests amended.