Make use of the new `is_muted` property (equals not in_home_view)
#3,285 opened on Jan 16, 2019
Repository metrics
- Stars
- (1,348 stars)
- PR merge metrics
- (PR metrics pending)
Description
No immediate action is required, but this is a notification for the mobile team about an API upgrade for stream muting we've been doing in https://github.com/zulip/zulip/pull/10220. It's completely backwards-compatible and should merge in the next day or so.
Historically, you knew whether a stream was muted by looking at the in_home_view property of the Subscription object, which is pretty confusing as a name. Now, in page_params and other routes that fetch subscription objects, we send both in_home_view and is_muted, where is_muted always equals not in_home_view (and is a sane name for the thing that tells you whether a stream is muted). A legacy client should work fine by just ignoring the is_muted key, but ideally we'll want to migrate our code to use the is_muted key rather than in_home_view for readability (and eventually, we may stop sending for in_home_view entirely).
Additionally, a client can, when muting/unmuting a stream, pass the is_muted property rather than in_home_view. Whether that option is available can be determined by whether the is_muted property appears in the Subscription dicts (or the version cutoff for the next zulip/zulip release, if one wants to do it that way).
To avoid breaking backwards compatibility, right now when a stream is muted/unmuted by a client, the events system event we send is still just an in_home_view event because the structure of those events doesn't naturally support specifying two values. We might add a redundant one for is_muted before merging; I'll update this issue with notes on that after doing a bit more thinking about it.