This replaces the previous logic of triggering change() event.
(Also, when we trigger the change() event whole path for detecting
changes in a subsection are triggered which isn't good.)
This makes use of `settings_ui.disable_sub_setting_onchange` for
handling dependent `id_realm_disallow_disposable_email_addresses`
checkbox when `id_realm_restricted_to_domain` is changed.
On discarding changes made for `realm_create_stream_permission` always
"by_admin_user_with_custom_time" get selected because
`create_stream_by_admins_only` isn't a valid page_param.
For forms that are built early in setting up the settings panel,
we don't want to attach multiple submit handlers every time we
go into the gear menu, so we use "off" to clear any old handlers.
We also attach handlers directly to the form, instead of
using delegation up to the container div.
Also, we remove unnecessary tips regarding modification settings.
Remove 'Only organization administrators can edit these settings'.
Remove 'Anyone in this organization can add user groups'.
Before this commit when we press enter in the text-input field the
first subsection get saved because a click event is triggered for
the first save button (of first subsection) irrespective of the
location of text input field in the whole form which is expected
as a default behavior of the forms.
The simple fix is to make the button of type "button" and override
action of "enter" in an input field.
More info at https://stackoverflow.com/a/12914700/7418550 and
https://stackoverflow.com/a/7060762/7418550
This makes each subsection of org-permissions independent from the
perspective of saving changes.
All the behavior we have for org-settings are also ultimately
reflected here as well like individual "Save" button for each
subsection, "Discard" button for discarding changes done in a
subsection and appearance of this button only when required.
In the new function, property values are handled more carefully i.e.
we first check whether property_name refers to a property values
which we can't get from the value of input elements like we have in org
permissions section for properties like realm_add_emoji_by_admins_only
where we have used dropdown and hence we get a string value but we
expect a true/false (check/uncheck) value.
Also, it is better to trigger a `change` event after changing a value
because we have properties which are dependent on the values of another
settings. Previously we trigger `click` event for checkboxes but
there exist some settings other than checkboxes like dropdown
for realm_create_stream_permission where realm_waiting_period_threshold
only appears after selecting custom values for threshold value from
dropdown.
In this refactor property values are handled more carefully i.e.
we first check whether property_name refers to a property values
which we can't get from the input elements like we do have in org
permissions section for properties like realm_add_emoji_by_admins_only.
Small refactor in property_value_element_refers is to prevent many
return statements on further addition of property names.
This changes failed status element to use class
`.admin-realm-failed-change-status` rather than id so that we can use
the same code in `save_organization_settings()` in future to refer to
failed-status element of that section.
To keep click handler for "save" button clean, we extracted the
the `if` statements where we complete request data for certain fields
which aren't mentioned in `property_types`.
This will reset the changes done in a subsection to the current ones
in page_params.
It will only appear when there are some user-provided changes to be reset.
With this "Save" button is only shown when there are changes in a
subsection. This means if we changed a setting and reverted it back to
original ones, then, "Save" button will get disappear. Hence, we're shown
"Save" when there are some property changes to send to the server.
This makes each subsection(like "Message feed") independent of changes
done in any other subsection and the save button of each subsection
saves the changes done in that subsection only.
To populate data for requests limited to only selected input elements,
we have to extend `populate_data_for_request` for objects other
than `property_types`, e.g. now we can collect data only for user identity
by passing org_permissions.user_identity as changing_property_types.
This splits property types according to sections in
"Organization settings" viz. Organization settings, Organization
permissions, and Organization profile. Where org. settings and
org. permissions are further categorized according to the
subsections.
These changes are made to save changes for each subsection independently.
`update_message_topic_editing_pencil` function update edit
icon for message topic in message row header.
- Remove erroneous `meta.loaded` check.
- Add proper check of message editing permission in realm
before updating message-topic-edit-icon in function.
- Update `always-visible-topic-edit` element in function
simultaneously.
Rename `toggle_allow_message_editing_pencil` to
`update_message_topic_editing_pencil` in `settings_org.js`.
As this function update the pencil icon for updating message
topic in message row header.
We have some settings which are inter-dependent. If one setting
is checked or unchecked, it's dependent-sub-setting get disabled
or enabled. i.e. If user unchecked setting allow-message-editing
then message-editing-time-limit setting should get disabled in UI.
Add generic function to change disable attribute of sub settings
on checked or unchecked event of main setting in `settings_ui.js`.
Rather than having a toggle function that just flips the state, it's
more correct to have the state just be set to what it should be.
Also, we clean up the use of .attr() for a thing better accessed via
.prop().
We should probably rename the function at this point, but we save that
for a future commit.
This adds button under "Organization profile" settings, which
deactivates the organization and sends an "event" to all the
active user and log out them.
Fixes: #8212.
On the "Organization settings" page, we had two Save buttons
for admins that had identical markup. This was confusing for
people reading the code. Now the two buttons have different
markup and individual, targeted click handlers (albeit still
calling the same function to do most of the work).
The context of this fix is that I was debugging a
Casper flake where our Casper tests were essentially clicking
on the same button twice. Depending on the timing,
the second button click could cause a "No changes saved!"
behavior that confused the Casper test. It is unclear whether
Casper was clicking both buttons here (in which case this fix
is necessary) or the same button twice (in which case this fix
just removes a nasty red herring for debugging).
The code still has the flaw that both buttons basically submit
the same data to the server, despite the appearance on the page
that there are two forms. The best fix for that is probably
just to move the Language/Notifications stuff to another
panel. I wanted to avoid touching this code altogether, but
the minor modifications here were necessary to improve the
Capser testing situation.
To toggle email change display, replace display = None
to disabled = true.
Email field shouldn't be removed from settings, it should only
disabled if email changes are disabled in realm.
This commit adds a setting to limit creation of generic bots
to admins for realms that want that restriction. (Generic
bots, apart from being considered spammy on some realms,
have less locked down permissions than webhook bots).
Fixes#7066.
The list needs to be set to use perfectScrollbar so that it can
scroll due to the fact that it resides within another instance of
perfectScrollbar.
Fixes: #6351.
Use jQuery DOM construction methods, rather than string concatenation,
to keep things structured and to stay clear of the lint rules introduced
in ee6235d71.
If we use string concatenation to span i18n strings across multiple
lines then we end with such strings to be translated by the translators:
```
"This is the first line"\n + "This is the second line"
```
We should use variables in i18n strings to give proper context to the
translators. If the pattern is this:
```
i18n.t("Count " + count + " items")
```
Then it will be captured like this:
```
{"Count" + count + "items": ""}
```
Which is not good for the translators.
This restructures organization settings and permissions to be
more accurately grouped and for the permissions page to not be too
long.
CHANGES:
PROFILE:
(this was split out)
organization-profile-admin.handlebars:
form #1:
name
description
(SUBMIT)
avatar:
(UPLOAD)
(DELETE)
SETTINGS:
organization-settings-admin.handlebars:
language (mostly untouched)
message editing:
time limit/history/retention
message feed:
mandatory-topics
preview images
preview websites
PERMISSIONS:
organization-permissions-admin.handlebars
(mostly stuff was removed)
Joining:
restrict domains
require invite
User Identity:
name changes
email changes
Streams/Emoji:
creating streams:
waiting period (ADDED)
adding emojis
(SUBMIT) for whole panel
The profile group (name, description, avatar) were split into a new
page that did not previously exist, and the permissions was stripped
of message settings (message editing, message feed), but keeping the
"waiting period" input and putting it in the "Streams & custom emoji"
section.
Fixes: #5844.
Using weird characters when filtering options items in these various
settings pages would throw exceptions whenever they didn't form a
valid regular expression.
This fixes a confusing bug where administrators would be offered the
convenient topic-edit pencil even if message editing was actually
disabled.
This doesn't yet fix the real-time sync issues of changing the setting
without reloading.
Fixes#5946.
This function no longer sets properties to false, so the supported
way of doing this is to instead use prop(foo, false). Some tests
had to be fixed to accommodate this.
In case the user was not allowed to upload an emoji, we were displaying
two different but sematically same tips. This commit merges them and
also updates `update_custom_emoji_ui()` function in settings_emoji.js
to live update tooltip.
This new setting controls whether or not users are allowed to see the
edit history in a Zulip organization. It controls access through 2
key mechanisms:
* For long-ago edited messages, get_messages removes the edit history
content from messages it sends to clients.
* For newly edited messages, clients are responsible for checking the
setting and not saving the edit history data. Since the webapp was
the only client displaying it before this change, this just required
some changes in message_events.js.
Significantly modified by tabbott to fix some logic bugs and add a
test.
The code now handles undefined stream_ids for realms that
don't have a notifications stream. It also removes unneeded
translation code on the stream name.
Added a dropdown in the organization settings page with a search-box and
required styles. Also added an element to disable it. Added a method to
populate the dropdown using list_rendering.js. Also altered response to
the event of deletion of the notifications stream on the frontend. On
selection of a new stream or on clicking 'Disable', a patch request is
made with stream-id to /json/realm.
Fixes: #3708.
Create property_types object for realm settings. In set_up function,
iterate over property_types to find settings that were updated, send those
new values to the server, and report that the changes were made.
Previously, the way the organization description textarea was
generated, there'd be a newline and ~12 spaces added each time on
reloaded the page and hit "save changes".
This change makes it so that the organization description only changes
when the user actually changes it.
Apparently, there were not correctly disabled if you clicked on
"authentication methods" after opening the settings UI another way.
Everything worked fine if you just clicked them, already.
We now wait to load Organization sections until you
click on the section (or virtually click by using arrow
keys).
Some of the sections are coupled in terms of their setup,
so some sections will already be loaded if you had clicked
on a related section.
This is mostly moving code, but we do add short-circuit logic
for some live-updating methods here.
Note that this affects two different sections of the admin app:
* Organization settings
* Authentication methods
We really want to move to one module per section, but there is some
legacy coupling that makes this difficult for now.