Changing the selected value of dropdown by `val` has more advantage
over `attr` especially in the case when dropdown value is chnaged
multiple times like due to events and discarding changes.
Though it is applicable to other elements but in this commit it is just
used for `id_realm_create_stream_permission` dropdown.
There are many question about this at stackoverflow:
https://stackoverflow.com/a/22093618/7418550https://stackoverflow.com/a/4837162/7418550
Since we don't have any string needed to be translated in
property_types we can move it outside `_setup` function to
get to the safe side if they needed to get accessed before
`_setup` is called.
This is a preliminary commit which includes settings' (checkboxes)
label as a context for rendering template.
The reason we did this in JS code because of translation issue when
passed (as a context in `partial` handlebars helper) directly within
template.
Currently this is done for notifications' settings.
(There will be no UI change)
Note from tabbott: This is a somewhat surprising feature to be adding
this late in Zulip's development, but the model we've had of what
narrows are easy to access via clicking around has meant that it was
fairly difficult to get into a narrow that didn't include the very
latest messages in that narrow.
Fixes#3465.
If individual messages arrive before we get the latest
messages from the server, they can create gaps in rendering,
and would often be offscreen anyway, so we just ignore them.
Earlier, we used to convert all occurrences of an emoticon on the
frontend. That behavior has been altered to do conversions only
when the emoticon has some terminal symbols around them, and not
any alphabet or number. Also adds tests for emoji conversions for
the above logic.
Fixes#8585.
With this we have the same way to save changes done in org profile
subsection, i.e. show "Save" button beside header of subsection,
add "Discard changes" button for org profile subsection and
show "Save" and "Discard" button only when needed.
Also, there is so much code which become obsolete which is removed
in this commit.
Based on extensive manual testing with print-debugg (the exact
situation here was highly reproducible), in the absence of this line
here or slightly above here, Chrome 64 will consistently trigger an
extra scroll-forward-by-12000-pixels size downward scrolling event
immediately after it finishes rendering the 5th batch of ~100 messages
one gets from hitting the End key in `near:1` narrows.
I don't understand clearly why this change would protect against such
a Chrome bug, but my best guess is that Chrome was doing some sort of
incorrect optimization, and querying the scrollTop was forcing it to
come to a clear conclusion about the scrolling position before
appending more content.
But runs with the scrollTop() line not present in that function show a
scrollTop of around 25K in `append()` just before the call to
`render()`, and 37K at the end; while runs with this scrollTop line
always show 25K both before and after, so it does seem to work.
Previously, when unnarrowing, we were calling this on the wrong
selector (this was missed years ago when we refactored Zulip to use
divs rather than table rows in the main message feed).
Noticed while debugging #5312.
Previously, if you started out with a very small window, loaded the
Zulip webapp, and then resized the window to be larger, you'd get the
condensed "[More]" links on essentially every message. This failure
mode was most visible with multi-protocol Electron apps like Rambox
that would sloppily start with a tiny window and then resize it when
loading Zulip.
The Rambox experience was essential to our being able to track this
down; once we knew what was happening, the fix was simply to
re-compute the condense state on resize.
Commit message rewritten by tabbott to explain the debugging and
context involved here, since this was one of our longest-lived mystery
bugs.
Fixes#5312.
This commit is similar to the prior commit, in that we are
more disciplined about setting up handlers. We set them up right
as the widgets get rendered, and the handlers only delegate
up to the container div (id="stream_creation").
We now wire up the handlers that correspond to elements in
the 'new_stream_users' template when we render that template,
rather than at startup time.
We also delegate the events only up to #people_to_add, rather
than all the way up to body/document.
This cleans repeating code in error callback in settings.
We made a generic function in `ui_report.js` which require two
arguments `xhr` and `btn`; we preferred `btn` over `row` as argument
because a row may have more than one buttons.
Fixes: #8788.
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.
This reverts success callback extension for `do_settings_change` function
because it seems it is better to make the request directly rather
than calling `do_settings_change`.
And hence `error` callback extension is also removed for the same
reason, but a error_continuation is added to do additional tasks when
errors happened.
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.
We only have one possible email hint, so there's no reason
to create one for each stream row, especially since we don't
clean them out when we close stream settings.
We don't have any consumers for this event after removing
some obsolete code related to subscribe buttons.
Handling this event reliably consumed about 75% of the time
spent in _post_process_dom_messages, and maybe a percentage
point or two of overall rendering, so this will be a minor
speedup.
In 18e43895ff we replaced
stream subscribe buttons with stream links. The new feature
has been well tested and well received for over a year now,
so it's safe to remove the older feature at this point.
Older sites will have super old messages that still have the
rendered markup; this commit does not attempt to address those
situations. Most likely, clicking on an old button in the old
message will either do nothing or look like a message reply.
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.
Applies the logic to allow community members to edit topics
of others' messages if this setting is True. Otherwise,
only administrators can update the topic of others' messages.
This logic includes a 24-hour time limit for community topic editing.
