Creates a shared `disabled_setting_tooltip` class that can be
reused in cases where a personal or organization setting button
or input is disabled and a tooltip is added to give information
about why the user cannot change/access the setting.
Changes `name-input` class, that was only being used in a div
wrapper for the input element for changing a user's full name,
to be a more specific id name: `full_name_input_container`.
This id is used to set or remove the disabled setting tooltip
when name changes are disabled by the organization.
There are no CSS rules set with this class/id.
Moves the tooltip when name changes are disabled to be shown on
hovering over the full name input field. Removes the question icon
that previously showed the tooltip on hover.
If the personal / organization settings overlay has not been
loaded to the DOM in the user's session, then there's no need
to update the overlay display for changes to the user's
permissions to update their name, email or avatar.
So we check for the relevant element ids before updating the
overlay display when the user's role or these organization
settings change, and return early if they are not present in
the DOM.
Disables the deactivate account button in the user's account and
privacy settings tab if they are the only active organization owner.
Adds a tooltip when hovering on the deactivated button to let the
user know why the button is disabled.
The backend already returns an error for self account deactivation
requests if the user is the only organization owner.
Adds `avatar.build_user_avatar_widget` to the updates done in
`settings_account.update_avatar_change_display` when the user
has permission to change/delete their avatar.
For the case where a user has their personal account profile
settings open while the organization or user's permissions are
changed, `user_avatar_widget_created` boolean is added to
`settings_account.js` to track whether the widget and handlers
have been created so that live updates don't rebuild the
existing widget and handlers.
Also, updates `avatar.build_user_avatar_widget` to return early if
the user cannot change their avatar. This pattern better matches
the other instances where we use the direct upload widget for the
organization icon and logos.
The `settings-info-icon` with the tooltip for the user avatar
section was removed in commit 103db2afaf. This removes the changes
to that tooltip in `settings_account.update_avatar_change_display`.
Instead of hiding or showing the `image_upload_button` in that same
live update function, we now add or remove the `hide` class, which
in the previous commit has a specific CSS hover rule for the image
upload widget.
Also adds test coverage for the `is_admin` case for this setting
because administrators can always change their own avatar even if
the organization has disabled avatar changes.
There are a few account settings that are possibly deactivated if
a user is not an administrator (email, name and avatar changes),
depending on the organization's policy for changing those settings.
When a user's role is updated to become (or no longer be) an admin,
the display for these account settings may need to be updated.
Adds `settings_account.update_account_settings_display` to the
functions called in `user_events.update_person` if the active
user's role is changed to or from an administrator role.
Moves the tooltip when email changes are disabled to be shown on
hovering over the email button text and pencil icon. Removes the
question icon that previously showed the tooltip on hover.
Moves the complicated logic in `account_settings.hbs` for whether
to disable the change email button (and show the tooltip) to
`settings_data.ts`.
This update mirrors how similar realm settings are handled,
such as `realm_name_changes_disabled`, and means that the
`realm_email_changes_disabled` bool is added to `page_params.ts`.
Prep commit for moving the email changes disabled tooltip from
a separate question icon to the disabled button itself.
We show tooltip for user read receipts setting mentioning
that the organization has disabled read receipts setting
when an organization does so. We hide the tooltip when
organization read receipts setting is enabled.
We also fix the alignment of "i" icons with label and headings
at various places by moving it 1 pixel below. There may be
some places where it is not fixed, but those will be fixed
separately.
The backend validates that URL inputs are RFC valid URLs (with no
specific length limit), but the frontend appears to have a maximum
length of 50 specified, likely because of a copy-paste error.
Increase the HTML maxlength for this input to 2048, which is a length
supported for URLs by all major browsers.
Fixes#21633
It was broken by commit f5fbf5f0e0
“change_password: Migrate modal to dialog_widget” (#20193), because
the new_password input didn’t exist when we tried to install an event
handler for it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We make the banner, mentioning the user to confirm new email
after changing the email through settings, sticky and it
disappears either on reload or after confirming the new email.
Fixes#20686.
This commit extends dialog_widget class by adding a new
optional paramter validate_input which will be a function
to validate the inputs in the dialog and will be called
before showing the spinner and calling the on_click function.
Currently, the password change modal uses this paramter to
validate that the old and new password inputs must not be
empty. Since the spinner will not be initiated in the case
where form is invalid, we need not hide the spinner after
showing the error and thus we can simplify the code to use
ui_report.error to show the error messages of empty fields.
We show "Please enter your password" error inside the modal
if the "Old password" input is empty and "Please choose a new
password" error if the "New password" input is empty and do
not send a request to server.
Fixes#19901.
A user wouldn't differentiate between a "normal" modal and a "settings"
modal. If one shows up instantly, one would expect all the others to do
the same. The difference between Bootstrap fade and non-fade is pretty
noticeable (300 ms for fading).
This is a prep commit for the Micromodal migration which will have 120ms
as the animation time which wouldn't feel slow.
We attach the DOM for the modal to the body element
to avoid style interference from other elements and having to choose
a separate parent element for every single dialog_widget.
Note: These are not functional in enabling/disabling sending of
typing notifications with this commit.
Refactored the privacy settings update to keep the code less
duplicated along with making the addition of new settings easier.
This isn't necessary as `settings_checkbox.hbs` template used
for presence enabled setting in `account_settings.hbs` takes
care of checking/unchecking this checkbox.
Move the password tracking variables from setup to channel module.
Track password_change requests in channel.
Directly use xhr object to store `password_changes` information.
Tests modified to accomodote this change by converting strings to
objects.
This commit changes the code to use container id in the
selector of the status element of presence_enabled setting
such that the correct element is selected because we will
add another element with same class in the realm-level
presence_enabled setting.
We have merged the '/settings/display' and 'settings/notifications'
endpoints to '/settings' in backend. This commit updates the frontend
code to '/settings' endpoint for updating notification settings
instead of '/settings/notifications' endpoint.
We have merged the '/settings/display' and 'settings/notifications'
endpoints to '/settings' in backend. This commit updates the
frontend code to '/settings' endpoint for updating display settings
instead of '/settings/display' endpoint.
We used html_submit_button to pass text to be present in the modal
submit button. There are only two possible options as of now -
"Confirm" and "Save changes" and the correct one can be determined
using is_confirm_modal parameter. So, we remove this paramter for
now and we can add it later if we have more type of modals using
this widget.
This commit adds a new dialog_widget.js file containing most
of the code of confirm_dialog.js with some minor changes and
changes confirm_dialog to be a wrapper around dialog_widget.js.
We pass 'is_confim_dialog' as true in dialog_widget for a
confirm_dialog modal. This commit also renames confirm_dialog.hbs
and confirm_dialog_heading.hbs to dialog_widget.js,
dialog_widget.hbs and dialog_widget_heading.hbs respectively.
This commit renames the variables, functions used in confirm_dialog.js
and classes and ids used in confirm_dialog.hbs.
This change is made so that we can easily migrate edit_fields_modal to
use this same code with some more changes.
We will change the file names and correspondingly import variables in
the next commit.
This commit renames the html_yes_button parameter of confirm
dialog widget to html_submit_button and also all the related
variables in confirm_dialog.js.
This will help in keeping a general name when deduplicating
the code for confirm_dialog and edit_fields_modal.
The presence setting is more suited in 'Account & privacy'
section as it is not related to notifications in anyway
and resembles privacy of user by allowing user to hide
his status of being online.
Lauryn Menard
Anders Kaseorg
Rohitt Vashishtha
Sahil Batra
Ganesh Pawar
Archisman Das
Mateusz Mandera
Dinesh
Aman Agrawal
sahil839