While editing custom profile fields, when user delete option(s) of
select type profile field, display that deleted option(s) in delete
option confirmation modal.
Follow-up: 21878
Disable "External account type" select field from External account type
profile field edit form, doing it because this select field is not
editable and it is incorrectly looks like editable.
This allows this component to follow existing design patterns, rather
than being its own unusual element with various quirks.
The implementation is approximately the same as before I just migrated
"Edit custom profile field" form into modal, like "Add new custom
profile field" form modal.
Fixes: #21634
This commit is a preparatory commit of "custom_profile_fields: Edit
custom profile field form into modal."
The object returned by get_profile_field_info, which contained jQuery
objects for the profile-field-row and profile-field-form elements, was
just a source of unnecessary indirection, since none of the functions
consuming it accessed the row.
This lets us remove this fairly ugly user interface widget, which was
inconsistent with the rest of the settings UI.
The implementation is approximately the same as before I just migrated
"Add new custom profile field" form into a modal, status update
notifications about these forms will be displayed inside their modal,
and made some little design changes as discussed on CZO.
Fixes part of: #21634
This is a preparatory commit for commit "Edit custom profile
field form into modal."
Above mentioned commit will use class input-group instead of
control-group so here we are already changing it to input-group.
There is no control-group class to hide/show in custom profile fields
list instead there is input-group class, kind of little typo I guess
from this 9e343f1 commit.
We show a confirmation modal when deleting option of a select-type
field mentioning number of users who are using that option. We also
show the modal if no user has selected that option. We show the modal
only in edit-form and not while creating a new profile field. We do
not show the modal when removing a newly added option during editing
the field.
Fixes#22145.
Previously, the value for an option of the select type custom
profile field was set as "order - 1". This commit changes it
to remain same even when we reorder the options or delete an
option. When we add a new option, its value is set as 1 more
than largest value already used.
This helps is eliminating various bugs in this subsystem, where
user's choice is changed unexpectedly when reordering or deleting
options.
Discussion -
https://chat.zulip.org/#narrow/stream/378-api-design/topic/custom.20profile.20fields.20option.20deletion.
In open_edit_form, we had an initialization order bug where we called
set_up_external_account_field_edit_form, which clears the field name
field if the external account is of the "custom" type, after
populating the initial values for edit form.
This resulted in these fields being displayed as empty in the UI for
this field type. Fix the issue by reordering the initialization.
Fixes: #21262.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Rename few functions referencing the "CHOICE" field to
instead use the new "SELECT" name. This is done so that they
can be reused in "SELECT_MULTIPLE" field.
Add input to filter in sortablejs config. This prevents drag
and drog from being called on clicking input field. Also
set preventOnFilter to false. This prevents disabling the
default behaviour on the click event.
Fixes#17619
Instead of prohibiting ‘return undefined’ (#8669), we require that a
function must return an explicit value always or never. This prevents
you from forgetting to return a value in some cases. It will also be
important for TypeScript, which distinguishes between undefined and
void.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
ES and TypeScript modules are strict by default and don’t need this
directive. ESLint will remind us to add it to new CommonJS files and
remove it from ES and TypeScript modules.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 114cc1ec25 (#15949) introduced a
subtle bug because sortablejs provides both a CJS module and an ES
module that expose different interfaces to CJS require() under
Webpack. This difference will disappear when we convert
settings_profile_fields to an ES module.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Yogesh Sirsat
Anders Kaseorg
Sahil Batra
aryanshridhar
tushar912
Steve Howell
Anders Kaseorg