Zulip: Add generic support for configuring organization default settings values for new users

[timabbott]

A lot of organizations have customizations that they want everyone on their team to do (e.g. defaults to night mode, notification settings, etc.). Building UI for a "default value" organization setting for each of these would be annoying, but we could probably create a generic UI that lets one set organization-level default values for large classes of these (i.e. the ones that use the property_types framework). We're imagine the UX for this would be something like:

• [ ] A typeahead where you enter the name of the setting (like "Night mode" or "Send email notifications for new logins to my account")
• [ ] Once you get the setting, you'll get a dropdown with "Zulip default", "Checked", "Unchecked" for checkboxes, and whatever other values are avaiable for other settings. These defaults would correspond to (no RealmUserDefault row) /True/False stored as that default in the database.

Implementation-wise, I think we'll want to structure this as follows:

• [ ] Add a new table, RealmUserDefault, to manage these values. Ideally, we want to avoid having to do manual work every time we add a new field to UserProfile to add it here. So I'd structure this as follows:
  
  
  
  • [ ] Extract an abstract base class to UserProfile called UserBaseSettings that UserProfile inherits, and move all the settings that will be supported by this feature to that base class. To start with, I'd just do the display_settings property type block. Done correctly, I believe this change should require no changes to tests or anything else.
  
  
  • [ ] Create RealmUserDefault, which just has a Realm foreign key and also inherits UserBaseSettings.
  
  
• [ ] Modify zerver/lib/create_user.py to look up the realm in RealmUser Default and adjust default values for these.
• [ ] Add backend API support for setting these defaults in zerver/views/realm.py; I think this mostly entails coming up with a good name transformation for the default property_types data; we can reuse the existing property_types validation logic as well. At this point, we can write good backend tests for the whole system.
• [ ] Add a basic frontend for this. I think for v1, it's possible we'll want to just use an existing property types / checkbox UI for the first one (probably default night mode), just to make sure we've hooked everything up correctly. And then from there, we can begin the project to do the more generic long-term UI described above.

See https://chat.zulip.org/#narrow/stream/31-production-help/topic/Default.20user.20settings/near/699017 for some discussion.

[zulipbot]

Hello @zulip/server-onboarding, @zulip/server-settings members, this issue was labeled with the "area: onboarding", "area: settings (admin/org)", "area: settings (user)" labels, so you may want to check it out!

[sahil839]

@timabbott I want to take up this issue. Can you help me from where I should start?
Should I start with creating a new table RealmUserDefault?

[OvermindDL1]

For now is there any way or workaround to default new members to specific settings for a given organization (specifically just need to change I think it was 2 settings)? :-)

[amartin3225]

+1

I can see 3 different ways to apply these default settings, so ideally this implementation would support all 3:

• force setting: this would force the setting value as the only option across the organization (e.g. make all users use night mode)
• default setting: this would make the setting value as the default for new accounts, but would leave existing accounts alone; users could still change the setting value at a later time
• default setting + reset existing: this would make the setting value as the default for existing and new accounts; users could still change the setting value at a later time

Is this possible?

[johnstewart]

+1 Customization of initial settings would be valuable.