(It is a preliminary change for deduplication of org settings template.)
This adds org settings labels as a context to admin templates so that
they can be used as a context variables in admin templates.
The reason we did this in JS code because of translation issue when
passed (as a context in `partial` handlebars helper) directly within
template.
This splits "Language and notifications" section into "Default user
settings" and "Notifications".
With this, we can easily add other default user settings in the
same place.
In our new system for updating realm settings, we don't need to create
separate functions to update the input elements for each feature.
Most of the work is done automatically by
`settings_org.sync_realm_settings`.
We are having a same code in `render_notifications_stream_ui`
and `render_signup_notifications_stream_ui` functions aside from
the HTML element. So this commit will remove the duplicate code in
`render_signup_notifications_stream_ui` and make use of
`render_notifications_stream_ui`.
Fixes#8886.
On IE11, ClipboardData isn't defined; one can instead access it with
`window.clipboardData`, but that doesn't support text/html, so this
code path couldn't do anything special anyway.
So we instead just let the default paste handler run on IE11.
Fixes#8850.
This reverts commit bcdd12773e.
We need to do some improvements in handling FetchStatus for initial
narrows before this will be safe to deploy in production.
There are several ways we open help for keyboard shortcuts,
markdown help, and search operators.
- from the gear menu
- from the compose box
- from the search box
- hitting ? for keyboard help
- arrowing/clicking through the tabs
This just moves the relevant code into a module and changes a
bunch of one-line calls in various places.
This adds some helpers to avoid some duplication, and we also
now track the selected idx directly, since it's all under our
control.
The main addition is `select_tab`, which we now use for some
things that used to simulate clicks.
Now that we have support for displaying custom profile fields, this
adds administrator-level support for creating them.
Tweaked by tabbott to fix a few small bugs and clean up the commit message.
Fixes#1760.
This initializes the bot_creation_policy_values after the page
is loaded.
Previously we initialize these values in `settings.js` when settings page
is loaded at least once, so if we open two tabs, one(1) in which we
haven't opened the settings page yet and if in another tab (2) we
update the `bot_creation_policy` value, then because of the event
which calls `settings_bots.update_bot_permissions_ui` causes exception
in (1) because `bot_creation_policy_values` isn't initialized yet.
Fixes: #8852.
This fixes a minor bug in which the value of `input` element of
`realm_waiting_period_threshold` don't get updated because in
`set_create_stream_permission_dropdwon` we don't change the
value of the input.
So, this minor refactor handles this more carefully.
This moves `sync_realm_settings` function out of `_setup` so that
we can call `settings_org.sync_realm_settings` without opening
settings page at least once.
This also fixes a minor bug in which if we have two tabs opened and
in one we haven't opened settings page at least once and in
another we change an org setting, then we get an exception in
the former tab because of the event as `sync_realm_settings`
isn't defined yet.
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.
Tim Abbott
Anurag Sharma
Shubham Dhama
Balaji2198
Aastha Gupta
Steve Howell
Akash Nimare
Umair Khan
Yago González
Rohitt Vashishtha
Marco Burstein
Puneeth Chaganti