This commit refactors code to handle realm authentication methods
in a better way. We remove the get_complete_data_for_subsection
function and instead let populate_data_for_request handle the
request data for authentication methods.
We also remove the "prop-element" class from each authentication
setting checkbox and instead add it to the container div as a
the list of those checkboxes represent a single field, i.e.
the realm_authentication_methods field received from the server
and the authentication_methods field sent to 'PATCH /realm'
endpoint.
This commit fixes the bug when updating
"Restrict email domains of new users?" setting by
adding data-setting-widget-type attribute to the select
element as get_input_element_value now expects every
element to have that attribute after 64c8262eaf.
Due to this change, we also need to update the code in
populate_data_for_request function to not send invalid
parameter in the request. This change resulted in some
refactoring which now helps in not passing in the
"disallow_disposable_email_addresses" and
"email_restricted_to_domains" when these fields are
not changed.
This commit fixes the bug when updating realm default
language setting by adding data-setting-widget-type
attribute to the relevant element with "prop-element"
class as get_input_element_value now expects every
element passed to it to have that attr after 64c8262eaf.
As a result we can now remove the code from
get_complete_data_for_subsection to handle realm
default language and just let get_input_element_value
handle it and it also helps in passing the parameter
unnecessary to request when the setting is not changed.
Fixes#29750.
- We introduced an argument called `custom_profile_field` similar to
`sub` and `group` in `check_property_changed` and
`populate_data_for_request`.
- We could've introduced `field` param in `get_input_element_value`,
but I've kept it clean since it didn't have any similar kind of data input.
The performance difference due to this should be negligible.
- Introduced a span that would be parent to all `field_data` params
since it is needed by the diff infrastructure.
- If there is no data to be changed, we display our success status
without sending the PATCH request since save changed button is
always enabled.
Previously, the stream permissions warning banner failed to hide
after changes to the stream's privacy settings were saved or discarded.
This fix addresses the issue, ensuring the banner behaves as expected
by disappearing when changes to make the stream private are either
saved or discarded.
Fixes: #29625.
Updates translated strings in web/ that do not need updates to any
tests. The majority of these strings are also unique to the file/
template that they are in. A few have overlap with one other file.
Some changes here update placeholders/variables in these strings to
no longer use stream so that all the translation updates for this
rename happen at the same time.
The exception to this are cases of "<z-stream>" placeholders in
these translated strings.
Part of the stream to channel rename project.
This commit refactors code to handle authentication methods
so that we need not update the type returned for
"realm_authentication_methods" by get_property_value
to be something different than what is the type for
realm object.
This change essentially means that we do not use the value
returned by get_property_value for authentication methods and
directly call realm_authentication_methods_to_boolean_dict.
Follow up to #29264.
The function check_property_changed is called at two places - we
pass elem as HTML object in one call and JQuery object in another.
We should make it consistent and we now pass HTML object in both
the calls as that would be better when we would convert
settings_components file to typescript.
We now pass HTML element to get_input_element_value instead of JQuery
object so that we can easily assert types later when we migrate the
file to typescript.
Only affects zulipchat, by being based on the BILLING_ENABLED setting.
The restricted backends in this commit are
- AzureAD - restricted to Standard plan
- SAML - restricted to Plus plan, although it was already practically
restricted due to requiring server-side configuration to be done by us
This restriction is placed upon **enabling** a backend - so
organizations that already have a backend enabled, will continue to be
able to use it. This allows us to make exceptions and enable a backend
for an org manually via the shell, and to grandfather organizations into
keeping the backend they have been relying on.
This commit adds a realm-level setting named
'zulip_update_announcements_stream' that configures the
stream to which zulip updates should be posted.
Fixes part of #28604.
This commit renames the realm-level setting
'signup_notifications_stream' to 'signup_announcements_stream'.
The new name reflects better what the setting does.
This commit renames the realm-level setting 'notifications_stream'
to 'new_stream_announcements_stream'.
The new name reflects better what the setting does.
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a second step, split
out the subset of fields that pertain to the entire realm.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a first step, split
out the subset of fields that pertain to the current user.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit updates the backend code to allow changing
can_access_all_users_group setting in development environment
and also adds a dropdown in webapp UI which is only shown in
development environment.
If the current value is not in the calculated options,
`text_if_current_value_not_in_options` can be provided to
the widget to show custom text in that case.
Used by stream / user announcement settings if user doesn't
have access to information about the currently selected stream.
This commit adds a dropdown and custom input element to set the
`realm_jitsi_server_url` when the video call provider is Jitsi. This
allows organization administrators to add a custom Jitsi server as the
organization's video call provider.
Fixes#17914.
Co-authored-by: Gaurav Pandey <gauravguitarrocks@gmail.com>
Since `settings_org.update_dependent_subsettings` handles settings whose
value and state depend on other elements and video chat provider settings
is an independent setting moving it out of update_dependent_subsettings.
This commit rename the existing setting `Who can invite users to this
organization` to `Who can send email invitations to new users` and
also renames all the variables related to this setting that do not
require a change to the API.
This was done for better code readability as a new setting
`Who can create invite links` will be added in future commits.
Because demo organization owners do not initially have an email
set, some of the personal and organization settings in the web-app
UI should be disabled/hidden until the owner configures an email
address for their account.
Disables configuring organization authentication methods in the
organization settings overlay until the user has configured an email
address. Adds a tip at the top of the authentication methods tab to
indicate why the authentication method checkboxes are disabled.
Organization owners can make streams private even if they're not
subscribed to them, but cannot access private streams they're not
subscribed to. This means they're able to lock themself out of streams.
This change warns users of this and give them a chance to subscribe.
Fixes#26437.
This commit adds a 'Default stream for new users' checkbox in
the stream editing UI to allow admins to easily add or remove
a stream as the default stream for new users. Previously, this
functionality required navigating to separate menu.
Fixes a part of #24048.
The save-discard was not being hidden properly in the below case-
- The "Default language for code blocks" setting was disabled
initially (i.e. the "Disable" option was selected in the dropdown),
meaning there was not default language set.
- The setting is then udpated to "javascript" and the save-discard
widget is shown as expected.
- The setting is then again change to "Disable" option.
The save-discard widget should have been hidden after the last
step, but it does not.
This was because while comparing the old and new value, the new
value (obtained using get_dropdown_list_widget_setting_value) was
computed as "null" while the old value (obtained from page_params)
was an empty string "". This commit fixes the bug by changing
get_dropdown_list_widget_setting_value to return empty string "",
instead of null, when the "Disable" option is selected in the
dropdown.
The "get_dropdown_list_widget_setting_value" function was returning
null previously, as we supported both null and empty string "" to
represent the state of no language selected, with null being the
initial value and empty string being used if user changed the
setting to some language and then disabled it again.
This was changed in #26275 and the state of not setting any default
language for code blocks is now represented using empty string in
all cases.
It is possible that the current value of a dropdown widget is
valid but not present in options since the current user doesn't
have access it. So, we show [disabled] as value in that case.
This can be reproduced by setting a private stream for
notifications in org settings and then opening org settings
as a user which doesn't have access to the private stream.
Earlier the API endpoints related to streams accepts and returns a
field `can_remove_subscribers_group_id` which represents the ID
of user_group whose members can remove subscribers from stream.
This commit renames this field to `can_remove_subscribers_group`.
This commit adds privacy icons before the stream names in
dropdown-list widget for "New user announcements",
"New stream announcements" settings and for stream dropdown
in "Move message" and "Move topic" modal.
Fixes part of #22355.
Added a 'Deactivate Organization' button inside the
'Personal Settings > Account & Privacy'. This button only appears
when the organization owner is the only user present. To verify this,
I used the 'get_active_human_count' function from the 'people.js'.
To remove duplication, a function has been created inside settings_org
file to handle the click event for the two buttons present inside
personal_settings and organization_settings that perform the same
action of deactivating organization. The click handler is defined in
the click_handlers.js file, which calls the dialog for deactivating
the organization. Previously, the error used to appear at the top of
the organization_settings, but now it appears inside the dialog box
itself.
To remove the duplication of two buttons having the same IDs,changed
the Id `deactivate_realm_button` to a className.
Fixes: #24105
Sahil Batra
afeefuddin
Shubham Padia
Akarsh Jain
Lauryn Menard
Mateusz Mandera
Prakhar Pratyush
Aman Agrawal
Anders Kaseorg
evykassirer
CIC4DA
Hemant Umre
Vector73
Ujjawal Modi
Alex Vandiver
Palash Baderia