-
Notifications
You must be signed in to change notification settings - Fork 248
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 topic muting/unmuting/following #1041
Changes from all commits
3e7683d
1e04f7b
868f8b7
df10d69
b1767b2
8540c29
7b74c06
585ef8b
4404537
9f18c53
c5f1cd4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,7 @@ | ||
import 'package:json_annotation/json_annotation.dart'; | ||
|
||
import '../core.dart'; | ||
import '../model/model.dart'; | ||
part 'channels.g.dart'; | ||
|
||
/// https://zulip.com/api/get-stream-topics | ||
|
@@ -38,3 +39,51 @@ class GetStreamTopicsEntry { | |
|
||
Map<String, dynamic> toJson() => _$GetStreamTopicsEntryToJson(this); | ||
} | ||
|
||
/// Update a topic's visibility policy. | ||
/// | ||
/// This encapsulates a server-feature check. | ||
// TODO(server-7): remove this and just use updateUserTopic | ||
Future<void> updateUserTopicCompat(ApiConnection connection, { | ||
required int streamId, | ||
required String topic, | ||
required UserTopicVisibilityPolicy visibilityPolicy, | ||
}) { | ||
final useLegacyApi = connection.zulipFeatureLevel! < 170; | ||
if (useLegacyApi) { | ||
final op = switch (visibilityPolicy) { | ||
UserTopicVisibilityPolicy.none => 'remove', | ||
UserTopicVisibilityPolicy.muted => 'add', | ||
_ => throw UnsupportedError('$visibilityPolicy on old server'), | ||
}; | ||
// https://zulip.com/api/mute-topic | ||
return connection.patch('muteTopic', (_) {}, 'users/me/subscriptions/muted_topics', { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Moving this from a code comment to the commit message doesn't make it more convincing 🙂—as I understand it, the reason we don't catch the error is the same reason we don't generally catch API errors in the binding layer: we want the bindings to correspond as closely as possible to the documented API, as a thin wrapper, so they don't hide or mess with things that callers might be interested in. I see just one /// Convenience function to get a single message from any server.
///
/// This encapsulates a server-feature check.
///
/// Gives null if the server reports that the message doesn't exist.
// TODO(server-5) Simplify this away; just use getMessage.
Future<Message?> getMessageCompat(ApiConnection connection, {
required int messageId,
bool? applyMarkdown,
}) async {
final useLegacyApi = connection.zulipFeatureLevel! < 120;
if (useLegacyApi) {
final response = await getMessages(connection,
narrow: [ApiNarrowMessageId(messageId)],
anchor: NumericAnchor(messageId),
numBefore: 0,
numAfter: 0,
applyMarkdown: applyMarkdown,
// Hard-code this param to `true`, as the new single-message API
// effectively does:
// https://chat.zulip.org/#narrow/stream/378-api-design/topic/.60client_gravatar.60.20in.20.60messages.2F.7Bmessage_id.7D.60/near/1418337
clientGravatar: true,
);
return response.messages.firstOrNull;
} else {
try {
final response = await getMessage(connection,
messageId: messageId,
applyMarkdown: applyMarkdown,
);
return response.message;
} on ZulipApiException catch (e) {
if (e.code == 'BAD_REQUEST') {
// Servers use this code when the message doesn't exist, according to
// the example in the doc.
return null;
}
rethrow;
}
}
} In that case we have an explicitly thicker wrapper (marked "compat") that encapsulates a difference between legacy and current behavior, so callers don't have to think about the two behaviors separately. (Because of that That kind of encapsulation might actually be a fine reason to want to "filter out" these errors in this binding layer, I'm not sure. But if that's the reason, it's not clear from your paragraph about it. Are the errors useful on those legacy servers, or are they basically just an API wart? Let's write an opinion on that first, if we're going to talk about dropping things from the server, instead of just saying we don't drop things because we can't drop them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah. The story is that the caller of this is not expected to handle the error, mostly because it isn't helpful to the user. If the topic is already muted/unmuted, and that the user wants it to be muted/unmuted, respectively, there really isn't anything that requires actions from the user: api: Add route updateUserTopic
For the legacy case, there can be an error when muting a topic that
- is already muted or unmuting one that is already unmuted. Let it
- throw because we can't reliably filter out the error, which doesn't
- have a specific "code".
+ is already muted or unmuting one that is already unmuted.
+
+ The callers are not expected to handle such errors because they aren't
+ really actionable. |
||
'stream_id': streamId, | ||
'topic': RawParameter(topic), | ||
'op': RawParameter(op), | ||
}); | ||
} else { | ||
return updateUserTopic(connection, | ||
streamId: streamId, | ||
topic: topic, | ||
visibilityPolicy: visibilityPolicy); | ||
} | ||
} | ||
|
||
/// https://zulip.com/api/update-user-topic | ||
/// | ||
/// This binding only supports feature levels 170+. | ||
// TODO(server-7) remove FL 170+ mention in doc, and the related `assert` | ||
Future<void> updateUserTopic(ApiConnection connection, { | ||
required int streamId, | ||
required String topic, | ||
required UserTopicVisibilityPolicy visibilityPolicy, | ||
}) { | ||
assert(visibilityPolicy != UserTopicVisibilityPolicy.unknown); | ||
assert(connection.zulipFeatureLevel! >= 170); | ||
return connection.post('updateUserTopic', (_) {}, 'user_topics', { | ||
'stream_id': streamId, | ||
'topic': RawParameter(topic), | ||
'visibility_policy': visibilityPolicy, | ||
}); | ||
} |
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.
Bump on #1041 (review) :
The
Fixes:
line doesn't belong on this commit until we do that 🙂 or make it not part of #348.