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