Track `realmName` and `realmIcon` in database #1860

rajveermalviya · 2025-09-19T19:19:00Z

This doesn't yet handle RealmUpdateEvent, will send a follow-up PR for it.

Fixes-partly: #1036

chrisbobbe

Thanks, this will be helpful! Comments below.

Also:

Does the 'basic happy case' test in test/widgets/login_test.dart need to be updated in order to catch a bug where the values aren't stored properly on login? (Or to be more explicit about testing that?)
Let's leave a TODO(#668) to remember to update the database on events

chrisbobbe · 2025-09-19T20:25:03Z

lib/api/model/initial_snapshot.dart


  final bool realmEnableReadReceipts;

+  final Uri realmIconUrl;


api: Add realmName and realmIcon to InitialSnapshot

nit: realmIconUrl in commit message, right?

chrisbobbe · 2025-09-19T20:28:11Z

test/example_data.dart

    realmUrl: realmUrl ?? _realmUrl,
    realmName: realmName ?? 'Example Zulip organization',
-    realmIcon: realmIcon ?? '$realmUrl/icon.png',
+    realmIcon: realmIcon ?? _realmIcon,


_realmIcon is a relative URL, right? So this changes the behavior when realmIcon isn't passed to eg.serverSettings: before this change, it was an absolute URL (starting with realmUrl); now, it's a relative URL. Does the API specify what kind to expect? We should match that if so, otherwise probably just match the observed behavior. (Same with the initial snapshot.)

API docs don't specify that, but the example response there have "realm_icon": "https://secure.gravatar.com/…" URL, and on CZO the observed URL is /user_avatars/2/realm/icon.png?version=3. So, I guess it can be either ot those (absolute or relative).

Also GetServerSettingsResult.realmIcon was never read before so this change should be nfc, added a note for that in the commit message.

And separated this change to 6e0d9e4.

chrisbobbe · 2025-09-19T20:31:00Z

lib/model/database.dart

+  /// This corresponds to [GetServerSettingsResult.realmName].
+  Column<String> get realmName => text().nullable()();
+
+  /// The organization icon URL of the Zulip realm this account is on.


nit: can remove "organization", it's redundant with "Zulip realm"

chrisbobbe · 2025-09-19T20:31:26Z

lib/model/database.dart

+  /// The name of the Zulip realm this account is on.
+  ///
+  /// This corresponds to [GetServerSettingsResult.realmName].
+  Column<String> get realmName => text().nullable()();


Should we add a line like

/// Nullable just because older versions of the app didn't store this.

here and on realmIcon?

And in migrateLegacyAppData, maybe add lines like these:

--- lib/model/legacy_app_data.dart +++ lib/model/legacy_app_data.dart @@ -94,6 +94,8 @@ Future<void> migrateLegacyAppData(AppDatabase db) async { try { await db.createAccount(AccountsCompanion.insert( realmUrl: account.realm, + // no realmName; legacy app didn't record it + // no realmIcon; legacy app didn't record it userId: account.userId!, email: account.email, apiKey: account.apiKey,

chrisbobbe · 2025-09-19T20:39:34Z

lib/model/database.dart

 import 'package:drift/remote.dart';
 import 'package:sqlite3/common.dart';

+import '../api/route/realm.dart';


db: Store realmName and realmIcon in the Accounts table And update account creation during login to populate these fields from server settings. Updates: #1036

Hmm I haven't seen an Updates: <issue> line before; what does that mean?

Hmm, I just meant to relate to the issue that this commit partly fixes. I guess Related: or the more direct Fixes-partly: fits better here.

chrisbobbe · 2025-09-19T20:45:40Z

lib/widgets/login.dart

+        realmName: Value(widget.serverSettings.realmName),
+        realmIcon: Value(widget.serverSettings.realmIcon),


db: Store realmName and realmIcon in the Accounts table

At this commit, the values are never updated when they change on the server, even when the user registers an event queue. So they can potentially be out-of-date by weeks, months, years; so let's add a TODO here to update them on /register, and remove the TODO in the next commit when that gets done.

chrisbobbe · 2025-09-19T21:11:16Z

lib/model/store.dart

+    required String realmName,
+    required Uri realmIcon,
+  }) async {
+    assert(_accounts.containsKey(accountId));


There's an async gap before this caller, and normally we consider it possible that the account was logged out during an async gap. But I guess in this case, the async gap is for updating an account (await globalStore.updateZulipVersionData), and that can't successfully happen concurrently with deleting the account? Meaning this assert should actually always hold?

Added a check at the callsite of updateRealmData.

rajveermalviya · 2025-09-23T15:24:10Z

Thanks for the review @chrisbobbe! Pushed an update, PTAL.

chrisbobbe · 2025-09-24T01:16:07Z

Thanks! Looks good except it looks like these are still pending, from #1860 (review) :

Also:

Does the 'basic happy case' test in test/widgets/login_test.dart need to be updated in order to catch a bug where the values aren't stored properly on login? (Or to be more explicit about testing that?)

Let's leave a TODO(#668) to remember to update the database on events

rajveermalviya · 2025-09-25T14:27:37Z

Thanks @chrisbobbe! Sorry for missing those. Pushed another update, PTAL.

chrisbobbe · 2025-09-25T21:06:46Z

Thanks, LGTM! Marking for Greg's review.

NFC, because GetServerSettingsResult.realmIcon was never being read.

Fixes-partly: zulip#1036

This will populate these fields for the currently opened account in the database when the PerAccountStore loads.

gnprice

Thanks @rajveermalviya for building this, and @chrisbobbe for the previous reviews! Apologies this review is a few days delayed.

gnprice · 2025-10-02T00:44:27Z

lib/api/route/realm.dart


  final String realmName;
-  final String realmIcon;
+  final Uri realmIcon;


nit: do this before adding the corresponding field on InitialSnapshot; that way they agree from the beginning

gnprice · 2025-10-02T00:45:25Z

test/example_data.dart

-    realmIcon: realmIcon ?? '$realmUrl/icon.png',
+    realmIcon: realmIcon ?? _realmIcon,


nit: similarly, reorder so this and eg.realmIcon agree from the beginning

gnprice · 2025-10-02T00:52:56Z

test/widgets/login_test.dart

+          realmName: Value('Some organization'),
+          realmIcon: Value(Uri.parse('/some-image.png'))));


This seems like it distracts from the narrative of this test (which is about the web-auth flow, not about the realm name and icon). This is a classic example of data that should exist in order to make things realistic, but is boring.

Can we arrange for eg.selfAccount to already have these fields, with the same boring values that eg.serverSettings puts there? For example that's how this test already handles realmUrl, which is similarly boring.

gnprice · 2025-10-02T01:00:33Z

test/model/store_test.dart

+    check(globalStore.getAccount(selfAccount.id)).identicalTo(updated);
+    check(updated).equals(selfAccount.copyWith(


nit: can make the relationships here more explicit:

Suggested change

check(globalStore.getAccount(selfAccount.id)).identicalTo(updated);

check(updated).equals(selfAccount.copyWith(

check(globalStore.getAccount(selfAccount.id))

..identicalTo(updated)

..equals(selfAccount.copyWith(

gnprice · 2025-10-02T01:06:48Z

lib/model/store.dart

      await globalStore.updateZulipVersionData(accountId, zulipVersionData);
      connection.zulipFeatureLevel = zulipVersionData.zulipFeatureLevel;
    }
+    if (globalStore.getAccount(accountId) != null) {


Can this condition ever fail? /cc @chrisbobbe since you had a related question above.

Before this change, the next step here was to call PerAccountStore.fromInitialSnapshot, which already assumes (and asserts) that the account exists. So if there's a reason that can be untrue, then that's an existing bug.

But I don't think it can be. The step before this was either the previous conditional — which has a ! that throws if the account doesn't exist — or globalStore.updateZulipVersionData, which calls updateAccount, which returns the updated account and so guarantees that it exists.

rajveermalviya added the maintainer review PR ready for review by Zulip maintainers label Sep 19, 2025

rajveermalviya assigned chrisbobbe Sep 19, 2025

rajveermalviya requested a review from chrisbobbe September 19, 2025 19:22

chrisbobbe reviewed Sep 19, 2025

View reviewed changes

rajveermalviya force-pushed the pr-realm-name-icon branch 2 times, most recently from 3abe521 to 4403816 Compare September 23, 2025 15:20

rajveermalviya requested a review from chrisbobbe September 23, 2025 15:24

rajveermalviya force-pushed the pr-realm-name-icon branch from 4403816 to 035eb20 Compare September 23, 2025 19:51

rajveermalviya force-pushed the pr-realm-name-icon branch from 035eb20 to 8315782 Compare September 25, 2025 14:26

chrisbobbe requested review from gnprice and removed request for chrisbobbe September 25, 2025 21:06

chrisbobbe assigned gnprice and unassigned chrisbobbe Sep 25, 2025

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 Sep 25, 2025

rajveermalviya added 7 commits September 30, 2025 19:53

api: Add realmName and realmIconUrl to InitialSnapshot

5dbcb34

api: Change GetServerSettingsResult.realmIcon type to Uri, from String

52b3bbb

example data [nfc]: Use _realmIcon as default value in eg.serverSettings

ab52325

NFC, because GetServerSettingsResult.realmIcon was never being read.

db: Allow storing realmName and realmIcon to the Accounts table

96e87ff

Fixes-partly: zulip#1036

login: Store realmName and realmIcon while creating account

415b1e9

store: Update account with realmName and realmIcon from InitialSnapshot

f3e6429

This will populate these fields for the currently opened account in the database when the PerAccountStore loads.

store [nfc]: Add getters for realmName and realmIcon

765d19e

rajveermalviya force-pushed the pr-realm-name-icon branch from 8315782 to 765d19e Compare September 30, 2025 14:24

rajveermalviya mentioned this pull request Sep 30, 2025

share: Support switching accounts #1883

Open

gnprice reviewed Oct 2, 2025

View reviewed changes

		realmName: Value(widget.serverSettings.realmName),
		realmIcon: Value(widget.serverSettings.realmIcon),

		realmIcon: realmIcon ?? '$realmUrl/icon.png',
		realmIcon: realmIcon ?? _realmIcon,

		realmName: Value('Some organization'),
		realmIcon: Value(Uri.parse('/some-image.png'))));

		check(globalStore.getAccount(selfAccount.id)).identicalTo(updated);
		check(updated).equals(selfAccount.copyWith(

Track realmName and realmIcon in database #1860

Are you sure you want to change the base?

Track realmName and realmIcon in database #1860

Uh oh!

Conversation

rajveermalviya commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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!

rajveermalviya commented Sep 23, 2025

Uh oh!

chrisbobbe commented Sep 24, 2025

Uh oh!

rajveermalviya commented Sep 25, 2025

Uh oh!

chrisbobbe commented Sep 25, 2025

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!

Uh oh!

Track `realmName` and `realmIcon` in database #1860

Track `realmName` and `realmIcon` in database #1860

rajveermalviya commented Sep 19, 2025 •

edited

Loading