custom_profile_fields: Add 'Select multiple' field type #37018

PedroSimas4 · 2025-12-11T15:39:54Z

This PR adds support for a new custom profile field type: SELECT_MULTIPLE (ID 9). This allows administrators to define a list of fixed options (similar to the standard Select field), but enables users to select multiple answers via checkboxes.

Key Changes:

Backend: Added SELECT_MULTIPLE to models.py, added validation logic in validator.py (ensuring values are valid lists of option keys), and updated users.py to handle storage.
Frontend: Updated settings UI to allow creating these fields and the Profile UI to display selected values as a comma-separated list.
Storage: Data is stored in the database as a JSON-encoded list of strings (e.g., ["1", "2"]).

Fixes: #17495

How changes were tested:

Automated Tests:

Added backend tests in zerver/tests/test_users.py to verify creation, validation (invalid choices, malformed JSON), and storage logic.
Added frontend unit tests in web/tests/settings_profile_fields.test.cjs to verify the UI configuration logic.
Ran ./tools/test-all locally and all tests passed.

Manual Verification:

Verified the end-to-end flow:
Created a "Programming Languages" multi-select field in Organization Settings.
Edited a user profile to select multiple options (e.g., Python, Rust).
Verified that the profile displays "Python, Rust" correctly.
Verified that deselecting all options hides the field from the profile display.

Screenshots and screen captures:

Self-review checklist

[x] [Self-reviewed]

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review.

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

zulipbot · 2025-12-11T15:40:03Z

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

timabbott · 2025-12-11T20:06:42Z

zerver/models/custom_profile_fields.py

        (SELECT, gettext_lazy("List of options"), validate_select_field, str, "SELECT"),
+        (
+            SELECT_MULTIPLE,
+            gettext_lazy("List of options (multiple)"),


I wonder if "multiple" or something like "multiselect" would feel clearer to end users for this.

timabbott · 2025-12-11T20:07:38Z

zerver/tests/test_users.py

+        try:
+            field_type_id = CustomProfileField.SELECT_MULTIPLE
+        except AttributeError:
+            field_type_id = 9


This exception should never happen in a test; how did you end up writing this test code?

(I think you only use this in one place, so it should be inlined?)

timabbott · 2025-12-11T20:13:47Z

zerver/lib/users.py

            try:
                val_to_validate = orjson.loads(value)
-            except orjson.JSONDecodeError:
+            except orjson.JSONDecodeError:  # nocoverage


These comments should be in the previous commit that adds the code with the linter issue. Or better, just add coverage in that commit.

(Similarly for all the other backend changes in this second commit).

timabbott · 2025-12-11T20:17:12Z

web/src/user_profile.ts

+                        readable_values.push(option.text);
+                    }
+                }
+                const final_text = readable_values.join(", ");


I think you want to use one of the helpers from util.ts that use Intl.ListFormat to do this in an internationalized fashion. (Japanese doesn't use , as the separator, for example).

timabbott · 2025-12-11T20:18:07Z

web/src/user_profile.ts

+                    return undefined;
+                }
+                profile_field.value = final_text;
+            } catch {


What is the situation when this catch clause would fire?

Generally it's quite risky to write code that catches ANY exception, since if the code above grew a syntax error such that it always failed, it'd just use this fallback code here.

timabbott · 2025-12-11T20:18:32Z

web/src/settings_profile_fields.ts

+        );
+    } catch {
+        choices_data = [];
+    }


Similarly, why did you add this try/catch?

timabbott · 2025-12-11T20:19:16Z

web/src/custom_profile_fields_ui.ts

+                        selected_values.add(item);
+                    }
+                }
+            }


This is a lot of parsing code; can you add comments explaining what possible failures you're worried about here?

alya · 2025-12-11T20:22:36Z

On the UI side:

A screenshot of the dropdown that includes this type of field is missing.
The spacing between options is incorrect -- there needs to be more space on the left of the checkbox than the right, if we actually want to put them on the same line. I'd also like to see a screenshot that includes surrounding UI context, and has some options with long names. How is line-wrapping handled?

timabbott · 2025-12-11T20:29:33Z

This looks like a great first PR @PedroSimas4! FYI #api design > custom profile fields @ 💬 will need to be resolved before we can finalize the server part of the implementation.

.

PedroSimas4 · 2025-12-14T21:46:17Z

@timabbott @alya Thank you for the detailed feedback! I have updated the PR addressing all the points:

UI/UX & CSS:

Changed the field label to "Multi-select" as suggested.

Moved the inline styles to web/styles/settings.css and cleaned up the HBS template.

Fixed the flexbox wrapping and spacing for long values.

(Added screenshots of the Admin UI and Profile View).

Frontend Logic:

Switched to util.format_array_as_list for proper internationalization.

Replaced generic try/catch blocks with specific z.safeParse checks to handle data integrity safely without swallowing logic errors.

Backend & Tests:

Removed # nocoverage tags.

Added a regression test case in zerver/tests/test_users.py covering both invalid JSON input and corrupted field definitions.

Refactored the test flow to avoid the unnecessary try/except block for the field type constant.

Ready for another look!

alya · 2025-12-16T00:52:47Z

Hm, I still don't see a screenshot of the dropdown?

alya · 2025-12-16T00:59:33Z

"Multi-select" is more technical-sounding than I like. Let's just call it "Checkboxes" (following, e.g., Google Forms and SurveyMonkey). Flagged for discussion in #design > custom profile field types, in case there's feedback.

timabbott · 2025-12-17T00:17:25Z

Tagging @sahil839 for maintainer review once the renaming feedback above has been completed.

This commit introduces a new custom profile field type, SELECT_MULTIPLE (ID 9). This field allows administrators to define a fixed set of options, similar to the existing SELECT type, but enables users to choose multiple answers. Key implementation details: * Storage: Selected values are stored in the database as a JSON-encoded list of strings (e.g., '["1", "2"]'). * Validation: Added logic to `validator.py` to ensure that saved values are valid lists and that every selected item exists in the field's defined options. * Tests: Added backend tests in `test_users.py` to verify creation, validation, and storage logic.

This updates the web application to support the display and editing of the new 'Select multiple' custom profile field type. Changes include: * Settings UI: Admins can now create and edit multi-select fields in the organization settings. * Profile Display: The user profile now renders these fields as a comma-separated list of selected values. If no value is selected, the field is hidden to maintain a clean UI. * Tests: Updated `settings_profile_fields.test.cjs` and mocks to support the new field type ID. Fixes zulip#17495.

PedroSimas4 · 2025-12-17T21:24:02Z

Renamed the field to 'Checkboxes' as suggested

sahil839

I have only done review for the first commit currently. Will do the complete review tommorrow.

sahil839 · 2025-12-18T16:12:08Z

zerver/lib/validator.py

+    for item in items:
+        if item not in field_data_dict:
+            msg = _("'{value}' is not a valid choice for '{field_name}'.")
+            raise ValidationError(msg.format(value=item, field_name=var_name))


I think some code is missing like validating the data when creating a SELECT_MULTIPLE type custom field. This is for validating the value set by user for the custom field but there is no validation when an admin creates a SELECT_MULTIPLE type custom profile field.

sahil839 · 2025-12-18T16:19:16Z

zerver/lib/users.py

+                val_to_validate = orjson.loads(value)
+            except orjson.JSONDecodeError:
+                raise ValidationError(_("Invalid value (not valid JSON)."))
+        multiselect_validator = cast(


I don't why casting to a type is needed here. I think this is because SELECT_FIELD_VALIDATORS dict is being used to store validators for both SELECT and SELECT_MULTIPLE type fields when they have different return types.

I think we can store them differently if that is the case instead of using cast here.

sahil839 · 2025-12-18T16:20:10Z

zerver/lib/validator.py

    raise ValidationError(_("{var_name} is not a string or integer").format(var_name=var_name))


+def validate_select_multiple_field(var_name: str, field_data: str, value: object) -> Any:


I think we can use an explicit type here instead of Any.

sahil839 · 2025-12-18T16:21:35Z

zerver/tests/test_users.py

+        )
+
+        field.field_data = "invalid_json_definition"
+        field.save()


I am not sure if it is required to test such a case where DB needs to be updated manually to set invalid data and it is not possible to do so using API.

sahil839

Posted some comments in frontend code as well. I feel the try-catch blocks are not needed since we can expect valid JSON value from server where we already validate the data. Or would be good if you could highlight cases where JSON value can be invalid except for modifying the DB value manually.

sahil839 · 2025-12-19T12:20:02Z

web/src/custom_profile_fields_ui.ts

+        $container.find("input:checked").each(function (this: HTMLElement) {
+            const val = $(this).val();
+            if (val !== undefined) {
+                values.push(String(val));


Instead of using String here, above call to val() can be modified as const val = $<HTMLInputELement>(this).val()!.

sahil839 · 2025-12-19T12:38:39Z

web/src/custom_profile_fields_ui.ts

+                );
+            } catch {
+                field_choice_dict = {};
+            }


I don't think we need this try-catch block. We expect server to validate field_data when creating and updating the field so we can expect field.field_data to always be a valid json.

sahil839 · 2025-12-19T12:45:39Z

web/src/custom_profile_fields_ui.ts

+                // the expected schema (array of strings).
+                try {
+                    parsed = JSON.parse(current_val);
+                } catch {


Similarly for the field value as well, the server would validate the value when setting or updating it.

sahil839 · 2025-12-19T12:48:13Z

web/src/custom_profile_fields_ui.ts

+                const result = z.array(z.string()).safeParse(parsed);
+                if (result.success) {
+                    for (const item of result.data) {
+                        selected_values.add(item);


This breaks the behavior for single select type field where the selected value is not shown in UI. I guess would be good to just have separate if-blocks for single and multiple select fields, i.e. have is_select_field false for multiple select fields and instead have a different variable like is_multi_select_field.

sahil839 · 2025-12-19T12:55:17Z

web/src/settings_profile_fields.ts

+    // We wrap this in a try/catch so that if the field data is malformed
+    // (e.g. invalid JSON), the edit form still opens (showing empty choices)
+    // rather than crashing. This allows the admin to recover by re-entering choices.
+    try {


Is there any case that you can reproduce with invalid JSON without manually modifying the DB? If not we can remove this as well.

sahil839 · 2025-12-19T13:09:36Z

web/src/settings_profile_fields.ts

+                profile_field.field_data &&
+                (profile_field.type === field_types.SELECT.id ||
+                    profile_field.type === field_types.SELECT_MULTIPLE.id)
+            ) {


Is choices field computed here used in the below render_admin_profile_field_list? I don't think so because we do not show choices in the list.

zulipbot · 2026-01-06T02:08:45Z

Heads up @PedroSimas4, we just merged some commits that conflict with the changes you made in this pull request! You can review this repository's recent commits to see where the conflicts occur. Please rebase your feature branch against the upstream/main branch and resolve your pull request's merge conflicts accordingly.

zulipbot added size: XL area: settings (admin/org) new feature A proposed new feature for the product labels Dec 11, 2025

PedroSimas4 force-pushed the feature-checkbox-profile-field branch 3 times, most recently from fa04c95 to 56f7c05 Compare December 11, 2025 16:34

timabbott reviewed Dec 11, 2025

View reviewed changes

web/src/settings_profile_fields.ts

);

} catch {

choices_data = [];

}

Copy link

Member

timabbott Dec 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, why did you add this try/catch?

timabbott reviewed Dec 11, 2025

View reviewed changes

PedroSimas4 force-pushed the feature-checkbox-profile-field branch 3 times, most recently from 5c1315b to f98686f Compare December 14, 2025 21:21

timabbott assigned sahil839 Dec 17, 2025

timabbott added the maintainer review PR is ready for review by Zulip maintainers. label Dec 17, 2025

PedroSimas4 force-pushed the feature-checkbox-profile-field branch from f98686f to 2e1f1b6 Compare December 17, 2025 20:47

PedroSimas4 added 2 commits December 17, 2025 17:52

PedroSimas4 force-pushed the feature-checkbox-profile-field branch from 2e1f1b6 to 9735e8b Compare December 17, 2025 20:53

sahil839 reviewed Dec 18, 2025

View reviewed changes

sahil839 reviewed Dec 19, 2025

View reviewed changes

zulipbot added the has conflicts label Jan 6, 2026

		raise ValidationError(_("{var_name} is not a string or integer").format(var_name=var_name))


		def validate_select_multiple_field(var_name: str, field_data: str, value: object) -> Any:

Uh oh!

custom_profile_fields: Add 'Select multiple' field type #37018

Are you sure you want to change the base?

custom_profile_fields: Add 'Select multiple' field type #37018

Uh oh!

Conversation

PedroSimas4 commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zulipbot commented Dec 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timabbott Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

alya commented Dec 11, 2025

Uh oh!

timabbott commented Dec 11, 2025

Uh oh!

PedroSimas4 commented Dec 14, 2025

Uh oh!

alya commented Dec 16, 2025

Uh oh!

alya commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

timabbott commented Dec 17, 2025

Uh oh!

PedroSimas4 commented Dec 17, 2025

Uh oh!

sahil839 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!

sahil839 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!

zulipbot commented Jan 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

PedroSimas4 commented Dec 11, 2025 •

edited

Loading

timabbott Dec 11, 2025 •

edited

Loading

alya commented Dec 16, 2025 •

edited

Loading