It turns out the consistent `.prop()` approach I switched to a few
commits back didn't actually work. Instead, we establish consistency
by always using `.attr`, which does.
Usually, I'd go back and fix the older commits, but in this case it
feels not worth it.
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.
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 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.
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 commit add $.create(), which allows you to create a
jQuery object that just has a name to identify it, as opposed
to some selector or HTML fragment. It's useful for things that
are really used as stubs.
This also fixes a bunch of the existing tests to use $.create().
Before this fix, you could actually just do $('some-stub'), but
now we enforce that the input to $() looks like a valid selector
or HTML fragment, and we make some exceptions for things like
window-stub and document-stub.
Hopefully this will make it more explicit that zjquery does
not truly simulate DOM, but it instead allows you to dynamically
set what you want the results of $('foo').find(some_selector)
to be.
Before this commit, we were erroneously setting up parents
as part of add_child() calls, but it's not necessarily the
case that those children are immediate children, and therefore
the first object is not necessarily the immediate parent.
Tim Abbott
YJDave
ihsavru
Steve Howell
Vishnu Ks
Brock Whittaker
franziskagoltz
Joshua Pan
Sarah
Cory Lynch
Harshit Bansal
Steve Howell
Vishnu Ks
Aditya Bansal