Start Requiring Zulip Server 5 #904

PIG208 · 2024-08-22T21:00:31Z

Blocked by #267, but these are migrations that can happen in parallel. I imagine that there won't be much overhead rebasing this kind of changes.

Fixes: #268

PIG208 · 2024-08-23T21:13:30Z

The PR itself is ready, but we won't be ready to merge it until we refuse to connect to older servers. Going through some reviews will still be helpful, though.

chrisbobbe

Thanks for going ahead with this! This will be good to have ready to merge once #267 is done (that's on my plate right now). Small comments below.

chrisbobbe · 2024-08-27T03:18:35Z

lib/api/model/model.dart

@@ -205,7 +205,7 @@ class User {
  // bool isOwner; // obsoleted by [role]; ignore
  // bool isAdmin; // obsoleted by [role]; ignore
  // bool isGuest; // obsoleted by [role]; ignore
-  bool? isBillingAdmin; // TODO(server-5)
+  bool isBillingAdmin;


api: Mark isBillingAdmin as requried, relying on server 5+, FL 73+ While `realm_user` update events also have this field added at the same feature level, it remains optional. See "Feature level 73" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

I would just leave out the sentence about how isBillingAdmin remains optional in RealmUserUpdateEvent. That's the normal, expected thing to happen; it matches all the other person fields, in that they might be null if they didn't change in the event.

Also nit in summary line: 'required"

chrisbobbe · 2024-08-27T03:23:05Z

lib/api/model/model.dart

-    // This field is absent in `realm_users` and `realm_non_active_users`,
-    // which contain no system bots; it's present in `cross_realm_bots`.


api: Drop _readIsSystemBot, relying on server 5+, FL 83+

This comment still applies, right? The change made in FL 83 is just that is_cross_realm_bot stops being a name we have to care about. The comment can go above the defaultValue: false, and it seems like we should keep the test that confirms that false is chosen if is_system_bot is absent.

chrisbobbe · 2024-08-27T03:40:16Z

lib/api/model/model.dart

-        }
+      if (topic != null || prevTopic != null) {
+        // Both are present if the topic was edited
+        assert(topic != null && prevTopic != null);


The condition in this assert might happen because of unexpected data from the server. To validate data from the server, we'll want code that runs in production, and reserve asserts to check our own invariants that we maintain within the bounds of the app. Could replace the assert and comment with:

// Crunch-shell validation: both are present if the topic was edited topic as String; prevTopic as String;

PIG208 · 2024-08-27T04:33:54Z

Thanks! Updated the PR.

chrisbobbe · 2024-08-28T22:17:11Z

Thanks! LGTM except bump on this part of #904 (comment) :

it seems like we should keep the test that confirms that false is chosen if is_system_bot is absent.

PIG208 · 2024-08-29T06:56:07Z

Got that test back. Thanks for the review!

chrisbobbe · 2024-08-29T21:46:28Z

Great! Marking for Greg's review once he's back from vacation.

gnprice · 2024-09-07T04:56:35Z

BTW there's generally no need to push a revision when it's a pure rebase, with no merge conflicts or other changes. The update causes notifications, and doesn't really save effort later — there'll typically be another rebase anyway just before merge, and git rebase is a very easy step to do at merge time when there's no conflict to resolve.

(As it happens I'm just about to take a look at this PR, but it wasn't because of the notification from the revision just now; it was from scanning the list of PRs marked for my review.)

gnprice

Thanks @PIG208 for taking care of these, and thanks @chrisbobbe for the previous reviews!

Generally this looks great. Small comments below.

gnprice · 2024-09-07T05:03:20Z

lib/api/model/model.dart

-  bool? isBillingAdmin; // TODO(server-5)
+  bool isBillingAdmin;


nit in commit message:

api: Mark isBillingAdmin as required, relying on server 5+, FL 73+ See "Feature level 73" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

In the summary line, let's say User.isBillingAdmin rather than just isBillingAdmin. Similarly for fields in later commits.

That helps the reader place the field in the relevant context within the overall model.

In this case it also disambiguates things: there's an isBillingAdmin field over on RealmUserUpdateEvent too, and as a previous revision noted (as discussed in a previous review above), that one remains optional.

Yeah, I think the context info is pretty helpful. While the commit summaries get longer, it is justified for this kind of migration changes.

gnprice · 2024-09-07T05:13:59Z

lib/api/model/model.dart

-    // This field is absent in `realm_users` and `realm_non_active_users`,
-    // which contain no system bots; it's present in `cross_realm_bots`.
-    return (json[key] as bool?)
-        ?? (json['is_cross_realm_bot'] as bool?) // TODO(server-5): renamed to `is_system_bot`


nit in commit message:

api: Drop _readIsSystemBot, relying on server 5+, FL 83+

Can focus the summary on what changed in the API, rather than on the method name which is an implementation detail of our (now-deleted) code:

api: Drop is_cross_realm_bot fallback, relying on server 5+, FL 83+

gnprice · 2024-09-07T05:19:50Z

lib/api/route/realm.dart

-  final String? zulipMergeBase; // TODO(server-5)
+  final String zulipMergeBase;


These changes in the GetServerSettingsResult type are a bit sticky because this is where we learn the version of a server in the first place. For #267 we'll want to give a reasonable error message when the server is too old, and that'll probably include saying what version the server actually is (as well as the minimum version we support).

Ultimately we do want to keep modernizing this type, like the others. But there might be some wrinkles around how we handle it. I guess the bottom line is that the details of these particular changes might shift once we have an implementation of #267 in hand. (/cc @chrisbobbe)

gnprice · 2024-09-07T05:23:56Z

lib/model/store.dart

-  final UserSettings? userSettings; // TODO(server-5)
+  final UserSettings userSettings;


This should get a corresponding update in PerAccountStoreChecks.

(Similarly in other commits.)

gnprice · 2024-09-07T05:25:12Z

lib/api/model/web_auth.dart

-  final int? userId; // TODO(server-5) new in FL 108
+  final int userId;


This is one that especially benefits from identifying the class:

login: Mark userId as required, relying on server 5+, FL 108+.

so e.g.:

api: Mark WebAuthPayload.userId as required, relying on server 5+, FL 108+

Otherwise "userId" could be all sorts of things.

bump / nit: use api: for prefix, like for other API changes

(in this revision it's:

login: Mark WebAuthPayload.userId as required, relying on server 5+, FL 108+.

)

gnprice · 2024-09-07T05:27:17Z

lib/api/model/web_auth.dart

-        userId = int.tryParse(userIdStr, radix: 10);
-        if (userId == null) throw const FormatException();
-      }
+      int? userId = int.tryParse(userIdStr, radix: 10);


nit: since this is now initialized just once, make it final:

Suggested change

int? userId = int.tryParse(userIdStr, radix: 10);

final userId = int.tryParse(userIdStr, radix: 10);

gnprice · 2024-09-07T05:30:12Z

lib/api/model/events.dart

-  final int? userId; // TODO(server-5)
-  final bool? renderingOnly; // TODO(server-5)
+  final int userId;
+  final bool renderingOnly;


nit: this summary line seems to cover only one of the three changes here:

api: Mark renderingOnly as required, relying on server 5+, FL 114+

Can say "fields on UpdateMessageEvent" to skip listing all three of them in the crowded space of the summary line.

gnprice · 2024-09-07T05:34:18Z

test/example_data.dart

@@ -489,8 +489,8 @@ DeleteMessageEvent deleteMessageEvent(List<StreamMessage> messages) {

 UpdateMessageEvent updateMessageEditEvent(
  Message origMessage, {
-  int? userId = -1, // null means null; default is [selfUser.userId]
-  bool? renderingOnly = false,
+  int userId = -1, // default is [selfUser.userId]


How about:

Suggested change

int userId = -1, // default is [selfUser.userId]

int? userId, // default is [selfUser.userId]

That seems more conventional. The old code was odder because it had to deal with null being a valid value for the underlying field, and so not available to signify "use the default".

gnprice · 2024-09-07T06:10:36Z

lib/api/route/messages.dart

-///
-/// 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, {


nit in commit message:

See also: 631f4d68c58a84dff66a6a9a80322584f0d60152

Instead say:

See also commit 631f4d68c58a84dff66a6a9a80322584f0d60152.

That way it's clear this hex blob refers to a commit (implicitly one in this same repo).

Marked as TODO as this might change in the future. See zulip#904 (comment). See "Feature level 88" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

… required, relying on server 5+, FL 116+ See zulip#904 (comment). See "Feature level 116" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

PIG208 · 2024-09-10T18:26:12Z

Thanks for the review! Added some TODOs commits for GetServerSettingsResult changes, making them easy to drop, and addressed the issues from the review. This revision should be fairly readable with range-diff.

gnprice

Thanks for the revisions! Just a few comments below.

gnprice · 2024-09-16T23:35:31Z

lib/api/route/realm.g.dart

-      zulipMergeBase: json['zulip_merge_base'] as String?,
+      zulipMergeBase: json['zulip_merge_base'] as String,


This doesn't seem to have a corresponding change in realm.dart.

Presumably this came about as you made some edits and missed rerunning build_runner for one of them, or something like that. I am puzzled that our CI didn't complain, though — tools/check build_runner should have failed because this doesn't match what a freshly-generated file should say. So that would be worth trying to debug.

For future reference, this was fixed in #947.

gnprice · 2024-09-16T23:37:09Z

lib/api/route/realm.dart

+  // TODO: Modernize this once we get to #267
+  final String? zulipMergeBase;


This should keep a TODO(server-5) comment until we do actually modernize it. That way it naturally shows up in any future round of grepping for opportunities to modernize our API usage.

gnprice · 2024-09-16T23:38:01Z

lib/api/model/web_auth.dart

-  final int? userId; // TODO(server-5) new in FL 108
+  final int userId;


bump / nit: use api: for prefix, like for other API changes

(in this revision it's:

login: Mark WebAuthPayload.userId as required, relying on server 5+, FL 108+.

)

gnprice · 2024-09-16T23:41:28Z

lib/api/model/events.dart

-  final int? editTimestamp; // TODO(server-5)
+  final int editTimestamp;


nit: this doesn't seem accurate:

Fields including `userId` and `editTimestamp` are optional and act as alternatives to `renderingOnly` for older server versions.

since those fields are no longer optional.

I think the commit message can skip explaining the fallback that previously existed for renderingOnly. It's directly relevant only when looking at the past; and the details are in this commit's diff.

Yeah, "were" would be more accurate here. Leaving this out makes sense.

gnprice · 2024-09-16T23:43:17Z

lib/api/model/initial_snapshot.dart

 class UnreadDmSnapshot {
-  @JsonKey(readValue: _readOtherUserId)
  final int otherUserId;


nit:

api: Remove sender_id fallback for UnreadMessagesSnapshot.otherUserId, relying on server 5+, FL 119+

that's not the class this field is on 🙂

Good find! I should learn to not trust the diffs heading and be more careful from now on 😓

diff --git a/lib/api/model/initial_snapshot.dart b/lib/api/model/initial_snapshot.dart index 565d89fe..6be29e78 100644 --- a/lib/api/model/initial_snapshot.dart +++ b/lib/api/model/initial_snapshot.dart @@ -269,15 +269,9 @@ class UnreadMessagesSnapshot { /// An item in [UnreadMessagesSnapshot.dms]. @JsonSerializable(fieldRename: FieldRename.snake) class UnreadDmSnapshot { - @JsonKey(readValue: _readOtherUserId) final int otherUserId; final List<int> unreadMessageIds; - // TODO(server-5): Simplify away. - static dynamic _readOtherUserId(Map<dynamic, dynamic> json, String key) { - return json[key] ?? json['sender_id']; - } -

Ah, yeah, the diff-hunk headers can be misleading like that sometimes 🙂

… required, relying on server 5+, FL 116+ See zulip#904 (comment). See "Feature level 116" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

gnprice · 2025-07-04T05:04:08Z

We have #267 now, so this is something we could potentially merge when its code is ready. I've just rebased it atop current main.

gnprice · 2025-07-04T05:10:35Z

The comments in my previous round #904 (review) above were all addressed.

Skimming now, there are a few commits whose summary lines indicate they're not ready:
9f15154 TODO api: Add TODO to modernize GetServerSettingsResult.zulipMergeBase
c514b59 FIXME LINK api/notif [nfc]: Cut comment on FcmMessageChannelRecipient.streamId, relying on server 5+, FL 115+.
662ccae TODO api: Mark GetServerSettingsResult.realmWebPublicAccessEnabled as required, relying on server 5+, FL 116+

Other than that, it seems like these changes are probably ready. I guess I'll want to reread, though, at least briefly, since it's been most of a year since we put it on hold (awaiting #267).

chrisbobbe

Thanks @PIG208!

Here's a review, since this is marked for maintainer review—but probably Greg or I will end up making new revisions?

There are three TODO(server-5) comments left at the tip of the branch; I've commented on one in my review, and the other two are also small but snuck in after this PR was first written almost a year ago.

chrisbobbe · 2025-07-08T00:15:46Z

lib/api/route/realm.dart

-  final String? zulipMergeBase; // TODO(server-5)
+  // TODO(server-5): Modernize this once we get to #267.
+  final String? zulipMergeBase;


TODO api: Add TODO to modernize GetServerSettingsResult.zulipMergeBase Marked as TODO as this might change in the future. See https://github.com/zulip/zulip-flutter/pull/904#discussion_r1747943940. See "Feature level 88" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

I read the linked discussion, and this change can go ahead; it doesn't interfere with what we've implemented for disallow-connecting-to-ancient-servers.

(Ditto the corresponding change in the initial snapshot, which would have been more likely to have a conflict but also doesn't.)

chrisbobbe · 2025-07-08T00:24:16Z

lib/api/model/events.dart

@@ -797,13 +797,13 @@ class UpdateMessageEvent extends Event {
  @JsonKey(includeToJson: true)
  String get type => 'update_message';

-  final int? userId; // TODO(server-5)
-  final bool? renderingOnly; // TODO(server-5)
+  final int userId;


Discussion on this userId change: #api documentation > `user_id` in `update_message` event @ 💬

From that discussion (thanks @PIG208!) it sounds like we don't want to make userId required: we can expect the user_id key to always be present in the JSON, but it'll be null for rendering-only events.

So I think the change here is just to remove the TODO(server-5), in a separate commit that explains why we're not making it required.

chrisbobbe · 2025-07-08T00:29:41Z

lib/api/route/realm.dart

@@ -51,7 +51,7 @@ class GetServerSettingsResult {
  final String realmName;
  final String realmIcon;
  final String realmDescription;
-  final bool? realmWebPublicAccessEnabled; // TODO(server-5)
+  final bool realmWebPublicAccessEnabled;


TODO api: Mark GetServerSettingsResult.realmWebPublicAccessEnabled as required, relying on server 5+, FL 116+ See https://github.com/zulip/zulip-flutter/pull/904#discussion_r1747943940. See "Feature level 116" from Zulip API changelog: https://zulip.com/api/changelog Signed-off-by: Zixuan James Li <[email protected]>

as in a previous comment of mine: this is fine; no interaction with disallow-ancient-servers

PIG208 · 2025-07-08T01:13:25Z

Yeah. I think this mainly needs an update resolving the TODOs/new comments and a reread. I can get back to this tomorrow night (don't have my laptop with me today). Feel free to beat me to it if needed.

PIG208 · 2025-07-09T03:11:41Z

Pushed an update addressing the new TODOs and the comments above.

gnprice

OK, I've just read the whole PR; a few comments below.

Pushed one added commit:
f192a63 api: Cut User.isBillingAdmin, obsolete and gone in current servers

I'll also see about making the small other changes and rebasing.

gnprice · 2025-07-23T00:39:28Z

lib/api/model/model.dart

-  bool? isBillingAdmin; // TODO(server-5)
+  bool? isBillingAdmin; // TODO(server-10)


Since we didn't have any logic using this now-obsolete field, we don't have to wait before removing our code for it; we can go ahead and stop looking for the field now.

I'll add a commit to that effect.

gnprice · 2025-07-23T00:39:46Z

lib/api/model/web_auth.dart

-        userId = int.tryParse(userIdStr, radix: 10);
-        if (userId == null) throw const FormatException();
-      }
+      final int? userId = int.tryParse(userIdStr, radix: 10);


nit: omit boring types

Suggested change

final int? userId = int.tryParse(userIdStr, radix: 10);

final userId = int.tryParse(userIdStr, radix: 10);

… I guess the existing code just above for Uri.tryParse does the same thing, so this matches. Whatever, then; we can clean up them both if we're touching this code in the future.

gnprice · 2025-07-23T00:55:50Z

lib/api/model/model.dart

+        // Crunchy-shell validation: Both are present if the topic was edited
+        topic as TopicName;
+        prevTopic as TopicName;
+        hasMoved |= !topicMoveWasResolveOrUnresolve(topic, prevTopic);


This can be simpler:

final prevTopicStr = entry['prev_topic'] as String?; if (prevTopicStr != null) { final prevTopic = TopicName.fromJson(prevTopicStr); final topic = TopicName.fromJson(entry['topic'] as String); hasMoved |= !topicMoveWasResolveOrUnresolve(topic, prevTopic);

The one difference in behavior that way is that with this version, if a history entry has topic but not prev_topic, this code won't notice the mismatch; the other version would throw.

Which is fine. In general our API bindings don't aim to be a validator for correct server behavior; if the server includes something extraneous that they weren't looking for, they won't notice or complain.

The "crunchy shell" concept would come in if this layer of our code were going to pass this data on, to be consumed by other code deeper in the app (the "soft center"). When that's happening, it's important that the data that gets passed on be internally coherent. But here topic and prevTopic don't get passed on anywhere, except to this topicMoveWasResolveOrUnresolve call; and we don't make that call anyway unless they're both present.

gnprice · 2025-07-23T00:57:30Z

lib/api/core.dart

@@ -14,7 +14,7 @@ import 'exception.dart';
 ///
 /// When updating this, also update [kMinSupportedZulipFeatureLevel]
 /// and the README.
-// TODO(#268) address all TODO(server-5), TODO(server-6), and TODO(server-7)
+// TODO(#992) address all TODO(server-6), and TODO(server-7)


nit:

Suggested change

// TODO(#992) address all TODO(server-6), and TODO(server-7)

// TODO(#992) address all TODO(server-6) and TODO(server-7)

gnprice · 2025-07-23T00:58:35Z

lib/api/route/messages.dart

-///
-/// 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, {


nit in commit message: use 9 hex digits for commit IDs (https://github.com/zulip/zulip-mobile/blob/main/docs/style.md#mentioning-commits)

See also commit 631f4d68 .

While is_billing_admin has become required since feature level 73, it then got removed at feature level 363. See "Feature level 73" and "Feature level 363": https://zulip.com/api/changelog

We weren't using this; and since it's deprecated, we don't expect to ever use it in the future. Because this doesn't appear in the current API docs (except in a "Changes" note saying how it used to be there), it doesn't need even a commented-out tombstone, either, like we have for isGuest and some others. (This change is NFC on all well-behaved servers; it's not quite NFC only in that if a server now sends this field but with a value of an unexpected type, the old code would reject that as malformed and the new code won't notice or care.)

…n server 5+, FL 83+ See "Feature level 83" from Zulip API changelog: https://zulip.com/api/changelog

See "Feature level 88" from Zulip API changelog: https://zulip.com/api/changelog This does not interfere with our handling of disallow-connecting-to-ancient-servers, which does not rely on GetServerSettingsResult.

…er 5+, FL 88+ See "Feature level 88" from Zulip API changelog: https://zulip.com/api/changelog This does not interfere with our handling of disallow-connecting-to-ancient-servers, which does not rely on InitialSnapshot.

This was done at the API boundary in commit e6f4576. But the resulting simplifications can be propagated a bit further. See "Feature level 89" from Zulip API changelog: https://zulip.com/api/changelog

… 108+. See "Feature level 108" from Zulip API changelog: https://zulip.com/api/changelog

It is true that userId will always be present after feature level 114, but it can still be null (as of July 2025). So supporting Zulip 5.0+ only does not require changing the type of UpdateMessageEvent.userId. See CZO discussion: https://chat.zulip.org/#narrow/channel/412-api-documentation/topic/.60user_id.60.20in.20.60update_message.60.20event/near/2215174 API documentation: https://zulip.com/api/get-events#update_message

…d, relying on server 5+, FL 114+ See "Feature level 114" from Zulip API changelog: https://zulip.com/api/changelog See also: https://zulip.com/api/get-events#update_message

…relying on server 5+, FL 115+. See "Feature level 115" from Zulip API changelog: https://zulip.com/api/changelog See also: zulip/zulip#18067

…relying on server 5+, FL 115+ See "Feature level 115" from Zulip API changelog: https://zulip.com/api/changelog

…ired, relying on server 5+, FL 116+ See "Feature level 116" from Zulip API changelog: https://zulip.com/api/changelog

…, relying on server 5+, FL 118+ "topic" is no longer optional when the topic was edited, we also don't need to expect "prev_subject" as opposed to "prev_topic". See "Feature level 118" from Zulip API changelog: https://zulip.com/api/changelog See also: https://zulip.com/api/get-messages#response

…ing on server 5+, FL 119+ See "Feature level 119" from Zulip API changelog: https://zulip.com/api/changelog See also: https://chat.zulip.org/#narrow/stream/412-api-documentation/topic/register.3A.20When.20was.20.60unread_msgs.2Epms.5B.5D.2Eother_user_id.60.20added.3F

See "Feature level 120" from Zulip API changelog: https://zulip.com/api/changelog See also commit 631f4d6, which introduced this wrapper. Fixes: zulip#268

gnprice · 2025-07-23T01:18:10Z

OK, revised and updated. @chrisbobbe would you take a look at the revision?

PIG208 force-pushed the server-5 branch 4 times, most recently from de9d000 to 6984723 Compare August 23, 2024 20:40

PIG208 marked this pull request as ready for review August 23, 2024 21:11

PIG208 added the maintainer review PR ready for review by Zulip maintainers label Aug 23, 2024

chrisbobbe reviewed Aug 27, 2024

View reviewed changes

PIG208 force-pushed the server-5 branch from 6984723 to ac3b56a Compare August 27, 2024 04:33

PIG208 force-pushed the server-5 branch from ac3b56a to 594b962 Compare August 29, 2024 06:55

PIG208 force-pushed the server-5 branch from 594b962 to 08bab16 Compare August 29, 2024 17:45

chrisbobbe added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Aug 29, 2024

PIG208 force-pushed the server-5 branch from 08bab16 to 3a4496e Compare September 7, 2024 04:24

gnprice reviewed Sep 7, 2024

View reviewed changes

PIG208 force-pushed the server-5 branch from 3a4496e to 665bd08 Compare September 10, 2024 17:57

PIG208 force-pushed the server-5 branch from 665bd08 to 95a8714 Compare September 10, 2024 18:22

PIG208 requested review from gnprice and removed request for gnprice September 10, 2024 18:26

gnprice reviewed Sep 16, 2024

View reviewed changes

gnprice marked this pull request as draft September 16, 2024 23:48

gnprice force-pushed the server-5 branch from d238e43 to 556d5ec Compare July 4, 2025 05:03

gnprice marked this pull request as ready for review July 4, 2025 05:03

gnprice added maintainer review PR ready for review by Zulip maintainers integration review Added by maintainers when PR may be ready for integration labels Jul 4, 2025

chrisbobbe reviewed Jul 8, 2025

View reviewed changes

PIG208 force-pushed the server-5 branch from 556d5ec to d1d492b Compare July 9, 2025 03:10

PIG208 force-pushed the server-5 branch from d1d492b to b8b74ae Compare July 9, 2025 03:24

gnprice reviewed Jul 23, 2025

View reviewed changes

PIG208 and others added 15 commits July 22, 2025 18:11

api [nfc]: Update TODO on User.isBillingAdmin

e7f7191

While is_billing_admin has become required since feature level 73, it then got removed at feature level 363. See "Feature level 73" and "Feature level 363": https://zulip.com/api/changelog

api: Drop is_cross_realm_bot fallback for User.isSystemBot, relying o…

d76b49c

…n server 5+, FL 83+ See "Feature level 83" from Zulip API changelog: https://zulip.com/api/changelog

api: Mark GetServerSettingsResult.zulipMergeBase as required

d2bc6c1

See "Feature level 88" from Zulip API changelog: https://zulip.com/api/changelog This does not interfere with our handling of disallow-connecting-to-ancient-servers, which does not rely on GetServerSettingsResult.

api [nfc]: Further propagate InitialSnapshot.userSettings as required

fc4f5c1

This was done at the API boundary in commit e6f4576. But the resulting simplifications can be propagated a bit further. See "Feature level 89" from Zulip API changelog: https://zulip.com/api/changelog

api: Mark WebAuthPayload.userId as required, relying on server 5+, FL…

6752957

… 108+. See "Feature level 108" from Zulip API changelog: https://zulip.com/api/changelog

api: Mark UpdateMessageEvent.{renderingOnly,editTimestamp} as require…

f786838

…d, relying on server 5+, FL 114+ See "Feature level 114" from Zulip API changelog: https://zulip.com/api/changelog See also: https://zulip.com/api/get-events#update_message

api/notif [nfc]: Cut comment on FcmMessageChannelRecipient.streamId, …

34f89be

…relying on server 5+, FL 115+. See "Feature level 115" from Zulip API changelog: https://zulip.com/api/changelog See also: zulip/zulip#18067

api [nfc]: Cut comment on requiring stream_id from iOS APNs payload, …

39d1f4e

…relying on server 5+, FL 115+ See "Feature level 115" from Zulip API changelog: https://zulip.com/api/changelog

api: Mark GetServerSettingsResult.realmWebPublicAccessEnabled as requ…

876eafa

…ired, relying on server 5+, FL 116+ See "Feature level 116" from Zulip API changelog: https://zulip.com/api/changelog

api: Remove legacy getMessageCompat, relying on server 5+, FL 120+

9e15c00

See "Feature level 120" from Zulip API changelog: https://zulip.com/api/changelog See also commit 631f4d6, which introduced this wrapper. Fixes: zulip#268

gnprice force-pushed the server-5 branch from f192a63 to 9e15c00 Compare July 23, 2025 01:17

		// This field is absent in `realm_users` and `realm_non_active_users`,
		// which contain no system bots; it's present in `cross_realm_bots`.

		final String? zulipMergeBase; // TODO(server-5)
		final String zulipMergeBase;

		final UserSettings? userSettings; // TODO(server-5)
		final UserSettings userSettings;

		final int? userId; // TODO(server-5) new in FL 108
		final int userId;

	int? userId = int.tryParse(userIdStr, radix: 10);
	final userId = int.tryParse(userIdStr, radix: 10);

	int userId = -1, // default is [selfUser.userId]
	int? userId, // default is [selfUser.userId]

		zulipMergeBase: json['zulip_merge_base'] as String?,
		zulipMergeBase: json['zulip_merge_base'] as String,

		// TODO: Modernize this once we get to #267
		final String? zulipMergeBase;

		final int? editTimestamp; // TODO(server-5)
		final int editTimestamp;

		bool? isBillingAdmin; // TODO(server-5)
		bool? isBillingAdmin; // TODO(server-10)

	final int? userId = int.tryParse(userIdStr, radix: 10);
	final userId = int.tryParse(userIdStr, radix: 10);

	// TODO(#992) address all TODO(server-6), and TODO(server-7)
	// TODO(#992) address all TODO(server-6) and TODO(server-7)

Start Requiring Zulip Server 5 #904

Are you sure you want to change the base?

Start Requiring Zulip Server 5 #904

Uh oh!

Conversation

PIG208 commented Aug 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PIG208 commented Aug 23, 2024

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PIG208 commented Aug 27, 2024

Uh oh!

chrisbobbe commented Aug 28, 2024

Uh oh!

PIG208 commented Aug 29, 2024

Uh oh!

chrisbobbe commented Aug 29, 2024

Uh oh!

gnprice commented Sep 7, 2024

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PIG208 commented Sep 10, 2024

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gnprice commented Jul 4, 2025

Uh oh!

gnprice commented Jul 4, 2025

PIG208 commented Aug 22, 2024 •

edited

Loading