1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
use serde::{Deserialize, Serialize};
use crate::field_access;
/// Represents details on features the client supports that are relevant to the format of responses sent by the server.
#[derive(Clone, Copy, Debug, Eq, PartialEq, Deserialize, Serialize)]
#[serde(rename_all = "snake_case")]
pub struct ClientCapabilities {
notificaiton_settings_null: bool,
bulk_message_deletion: bool,
user_avatar_url_field_optional: bool,
stream_typing_notifications: bool,
user_settings_object: bool,
linkifier_url_template: bool,
user_list_incomplete: bool,
include_deactivated_groups: bool,
archived_channels: bool,
empty_topic_name: bool,
simplified_presence_events: bool,
}
field_access! {
ClientCapabilities {
/// `notification_settings_null`: Boolean for whether the
/// client can handle the current API with `null` values for
/// channel-level notification settings (which means the channel
/// is not customized and should inherit the user's global
/// notification settings for channel messages).
///
/// **Changes**: New in Zulip 2.1.0. In earlier Zulip releases,
/// channel-level notification settings were simple booleans.
notificaiton_settings_null: bool,
/// `bulk_message_deletion`: Boolean for whether the client's
/// handler for the `delete_message` event type has been
/// updated to process the new bulk format (with a
/// `message_ids`, rather than a singleton `message_id`).
/// Otherwise, the server will send `delete_message` events
/// in a loop.
///
/// **Changes**: New in Zulip 3.0 (feature level 13). This
/// capability is for backwards-compatibility; it will be
/// required in a future server release.
bulk_message_deletion: bool,
/// `user_avatar_url_field_optional`: Boolean for whether the
/// client required avatar URLs for all users, or supports
/// using `GET /avatar/{user_id}` to access user avatars. If the
/// client has this capability, the server may skip sending a
/// `avatar_url` field in the `realm_user` at its sole discretion
/// to optimize network performance. This is an important optimization
/// in organizations with 10,000s of users.
///
/// **Changes**: New in Zulip 3.0 (feature level 18).
user_avatar_url_field_optional: bool,
/// `stream_typing_notifications`: Boolean for whether the client
/// supports channel typing notifications.
///
/// **Changes**: New in Zulip 4.0 (feature level 58). This capability is
/// for backwards-compatibility; it will be required in a
/// future server release.
stream_typing_notifications: bool,
/// `user_settings_object`: Boolean for whether the client supports the modern
/// `user_settings` event type. If false, the server will additionally send the
/// legacy `update_global_notifications` and `update_display_settings` event
/// types.
///
/// **Changes**: New in Zulip 5.0 (feature level 89). This capability is for
/// backwards-compatibility; it will be removed in a future server release.
/// Because the feature level 89 API changes were merged together, clients can
/// safely make a request with this client capability and also request all three
/// event types (`user_settings`, `update_display_settings`,
/// `update_global_notifications`), and get exactly one copy of settings data on
/// any server version. Clients can then use the `zulip_feature_level` in the
/// `/register` response or the presence/absence of a `user_settings` key to
/// determine where to look for the data.
user_settings_object: bool,
/// `linkifier_url_template`: Boolean for whether the client accepts
/// [linkifiers](https://zulip.com/help/add-a-custom-linkifier) that use [RFC 6570](https://www.rfc-editor.org/rfc/rfc6570.html) compliant
/// URL templates for linkifying matches. If false or unset, then the
/// `realm_linkifiers` array in the `/register` response will be empty
/// if present, and no `realm_linkifiers` [events](https:/zulip.com/api/get-events#realm_linkifiers)
/// will be sent to the client.
///
/// **Changes**: New in Zulip 7.0 (feature level 176). This capability
/// is for backwards-compatibility.
linkifier_url_template: bool,
/// `user_list_incomplete`: Boolean for whether the client supports not having an
/// incomplete user database. If true, then the `realm_users` array in the `register`
/// response will not include data for inaccessible users and clients of guest users will
/// not receive `realm_user op:add` events for newly created users that are not accessible
/// to the current user.
///
/// **Changes**: New in Zulip 8.0 (feature level 232). This
/// capability is for backwards-compatibility.
user_list_incomplete: bool,
/// `include_deactivated_groups`: Boolean for whether the client can handle
/// deactivated user groups by themselves. If false, then the `realm_user_groups`
/// array in the `/register` response will only include active groups, clients
/// will receive a `remove` event instead of `update` event when a group is
/// deactivated and no `update` event will be sent to the client if a deactivated
/// user group is renamed.
///
/// **Changes**: New in Zulip 10.0 (feature level 294). This
/// capability is for backwards-compatibility.
include_deactivated_groups: bool,
/// `archived_channels`: Boolean for whether the client supports processing
/// [archived channels](/help/archive-a-channel) in the `stream` and
/// `subscription` event types. If `false`, the server will not include data
/// related to archived channels in the `register` response or in events.
///
/// **Changes**: New in Zulip 10.0 (feature level 315). This allows clients to
/// access archived channels, without breaking backwards-compatibility for
/// existing clients.
archived_channels: bool,
/// `empty_topic_name`: Boolean for whether the client supports processing
/// the empty string as a topic name. Clients not declaring this capability
/// will be sent the value of `realm_empty_topic_display_name` found in the
/// [POST /register](/api/register-queue) response instead of the empty string
/// wherever topic names appear in the register response or events involving
/// topic names.
///
/// **Changes**: New in Zulip 10.0 (feature level 334). Previously,
/// the empty string was not a valid topic name.
empty_topic_name: bool,
/// `simplified_presence_events`: Boolean for whether the client supports
/// receiving the [`presence` event type](/api/get-events#presence) with
/// user presence data in the modern format. If true, the server will
/// send these events with the `presences` field that has the user presence
/// data in the modern format. Otherwise, these event will contain fields
/// with legacy format user presence data.
///
/// **Changes**: New in Zulip 11.0 (feature level 419).
simplified_presence_events: bool,
}
}