These were removed in 953ee778f, along with the stream names and
right-sidebar user names mentioned in the commit message. But unlike
those, these don't get any background change on hover, so we need some
way to show the hover.
We can probably still do something that looks nicer than this, but
it's better than not having it.
This makes them roughly the same visual weight as the (non-muted)
stream icons below -- though that's imprecise because the latter
varies with color. Tested in both normal and dark-mode.
This reverts commit dd406e87e. Whatever awkward error message might
have motivated that change, we can fix in a more targeted way when we
see it again. This version would delete the potentially-informative
context the caller provided in `response` -- even just "Failed" --
based on whether an error message happened to contain a colon
somewhere in it, which is sure to end up feeling unpredictable.
The last bit of #8059 (merged as b875fe07) didn't get merged, so just adding
it as a followup.
The "Other notification settings" section will also eventually house the
"pick your notification sound" setting, which is why it isn't called "Other
email settings" or similar.
Users having only account in one realm will not be distracted by realm
name in subject lines of every email. Users who have multiple
accounts in realms can turn this setting on and receive a
corresponding realm name in email's subject.
Tweaked by tabbott to rebase and address a few small issues.
Fixes#5489.
This adds some styling to make the open graph previews look a bit nicer,
including:
1. Adding a bottom fading gradient to slowly fade out text that is out
of bounds rather than chopping it off.
2. Using font anti-aliasing to make the characters appear smoother.
3. Increasing the font size of the title to give it prominence.
4. Changing the height to 80px from 70px.
Also refactor the "panels"/banner code to be a bit clearer about how
it's supposed to generically work, using [data-process] as a uniquely
identifying marker.
Fixes: #8166.
[greg: rebased and squashed a series of fixup commits.]
The original code made a 3/4-hearted effort to generically accommodate
more banners/"panels" later, but named itself after the first one made.
[greg: expanded commit message.]
The issue is that the server wants to display an error when you make a
request and fail, but the jQuery form validator also wants to display
errors at the same time. This removes the server errors to display the
jQuery.
Fixes: #8239.
This properly vertically centers the deactivation modal in the
user settings section by setting the top to 50% and the transform
to -50% (50% of the height of the actual modal).
This is an alternate solution to #7888, which just removes the
animation, breaking the normal modal behavior.
The header had a padding of "20px 0 15px", which meant that there
was more padding on the top than the bottom, so it has been changed
to "15px 0" instead.
This is a partial revert of c5cdede891.
The added 4px padding made the dropdown pill not vertically center
within the portico header. This removes the padding as it was a
cosmetic change that was not necessary.
This is a partial revert of a37e993907.
In password modal, submit button's data-dismiss property should be
removed, as on data-dismiss we flush all data of form fields,
which results in passing empty string to json request.
We already flush all data of fields after compeletion of request.
This restores the property that changing one's name in on browser's
"account settings" also changes the user's name in other browser windows'
"account settings" pages.
This makes this UI widget more consistent with its neighbors.
tabbott: This introduces a bug with how the `full_name_field` HTML is
managed; it should be done via the `server_events.js` handler.
- When password fields are cleared, update password strength bar.
- On data dismiss, clear password fields.
- Exclude forgot-password div from focus.
- On enter key, modal should be submitted not dismissed.
- Change password btn text from "Change password" to "*****"
A comment like this was removed in
fa44d2ea6 "settings: Remove autoscroll_forever setting."
The comment went on to say something about autoscroll, but this
part still seems relevant. While here, adjust grammar and caps.
The first argument to the error callback is *usually* a string code
from a list in the filedrop source; but sometimes it was the text
the server sent in the HTTP status line, instead. The latter isn't
predictable, and so it's not possible to write app code that uses it
to handle error consistently.
Instead, use that parameter for the numeric HTTP status code. This
still isn't totally clean in that sometimes it's internal filedrop
errors, as strings, and sometimes it's HTTP status codes, as numbers;
but at least both of those are things we can sanely handle with a
`switch` statement.
Also pass through `serverResponse`, which for a nice JSON error from
the server will contain meaningful information about the error which
the calling code can use for nice error handling. And just drop the
HTTP status text, which at best is redundant with the numeric code.
In passing, fix one case where for no obvious reason filedrop was
passing the file object but not the index.
This should be a pure refactor.
We'll replace this primarily with per-realm quotas (plus the simple
per-file limit of settings.MAX_FILE_UPLOAD_SIZE, 25 MiB by default).
We do want per-user quotas too, but they'll need some more management
apparatus around them so an admin has a practical way to set them
differently for different users. And the error handling in this
existing code is rather confused. Just clear this feature out
entirely for now; then we'll build the per-realm version more cleanly,
and then we can later add back per-realm quotas modelled after that.
The migration to actually remove the field is in a subsequent commit.
Based in part on work by Vishnu Ks (hackerkid).
This brings the right sidebar UI to match the similar widget in the
left sidebar. Since there's no other plausible effect for a click in
this whitespace, this small tweak should make using Zulip a bit more
convenient.
Fixes#8161.
There is a bug on MacOS on Zulip where the categories are all
duplicated due to faulty looping logic, while also changing the Map to
an Array since maps have less cross-browser support.
This implementation never worked, for two reasons:
(1) The logic for getting the path to the katex package had invalid
syntax in the version of Node we use.
(2) The KaTeX package bundled by webpack doesn't seem to be importable
from Node at all.
Adds a check for newline that was present on backend, but missing in the
frontend markdown implementation. Updating messages uses is_me_message flag
received from server instead of its own partial test. Similarly, rendering
previews uses markdown code.
Fixes#6493.
This is done by using a bot's ID instead of email in
the handler methods for bot_data.bots and bot_data.services,
and updating all code paths involved.
Previoulsy, we display "0 subscribers" if user can't access stream's
subscribers. Replace subscriber count with lock icon in case of
unsubscribed private stream, in "All stream" list.
Display warning, saying "You can not access private stream subscribers,
in which you aren't subscribed", if user can not access subscribers;
instead of showing zero subscriber to stream.
In this we change the way 'Sending...' is displayed. Instead of
hardcoding it into the template we make change the paradigm so
that we can have a flexible message about what's happening
rather than just always saying 'Sending...'. For eg. this will
help in the upcoming feature of Scheduled Messages by having this
message say 'Scheduling...'.
This is a server setting so I created the section "Server settings" in the help sidebar for this to go under, and rewrote the copy and retook the images that were originally done by @Privisus due to some issues.
This also amends a commit from Brock Whittaker <brock@zulipchat.com>
that merges two separate functions for YouTube videos and Vimeo videos
into a generic video recall function.
Fixes#7550.
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.
The alert word highlighting is too light to work with the font
when it is white, so this changes it to have a translucent background
so that the color adjusts to be more visible on a darker background.
This is originally taken from #7844 and is a modification of the
solution in #7847.
The reason this approach is better for the codebase is now there is
only one color to change for alert words which reduces the likelihood
that someone in the future will change the color of one theme's
alert words and not the other.
Fixes: #7844.
An image link such as [example](http://www.example.com/example.png)
is supposed to be inlined by the backend. The regex
backend_only_markdown_re in markdown.js does not recognize this link
as an image link, causing issues when adding fixtures to
zerver/fixtures/markdown_test_cases.json .
This adds UI fields in the bot settings for specifying
configuration values like API keys for a bot. The names
and placeholder values for each bot's config fields are
fetched from the bot's <bot>.conf template file in the
zulip_bots package. This also adds giphy and followup
as embedded bots.
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.
For public stream, always show subscription option.
For private stream, if user is subscribed display unsubscribe option.
If user is not subscribe, do not display subscription option.
Only show edit option for stream name and description if user is admin and
either stream is public or stream is private and admin is subscribed to
private stream.
As per backend restrictions for editing stream name/description.
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.
This mostly moves code from server_events_dispatch, but
it also de-duplicates the logic in emoji_success(), and
it does early-return for the "text" case to keep the
function a bit flatter.
We no longer have a special UI setting and model
field ("emoji_alt_code") for saying users want text-only
emojis. We now instead make "text" be a fifth choice
for "emojiset".
Fixes#7406
We join extra text message for notification and xhr response text by ':'.
Before joining, check if xhr response text already include ':', to
prevent notification with more than one ':'.
This change has a few cleanups:
* We early-return on last_msg_container === undefined
to make the function flatter.
* We avoid comparing two boolean values for equality,
which can be a landmine if one of the values is
`undefined`, which is falsy but not actually `false`.
* We extract some local variables for readability.
* We make the conditions for subscribe/unsubscribe
more explicit.
This fixes a bug where this used to happen:
* Alice has not read a message
* Bob edits the message
* Alice immediately reads the message
* Bob's edit arrives to Alice and sets her
message status back to unread
Essentially, the root cause of the bug is that we update
message.unread for edits, possibly from stale data, even
though Alice has more current info about reading the message.
This is the final fix to that scenario. There were some
aggravating factors that widened the race window which were
fixed in earlier commits.
Fixes#6248
We were queuing up individual messages to be flagged as
read on the server before this change, and we used debounce
to avoid sending individual POSTs, but this created delays
that were ripe for race conditions.
Now we batch them in the caller and use throttle instead.
This now prevents us from slamming the server with lots of
individual requests, without as many opportunities for races.
(Note that we still have some possibility of race conditions,
but they should be rare now, and other commits will address
some of the other contributors to read/unread glitches.)
Once we convert message.flags to more specific boolean attributes
like message.mentioned and message.alerted, we should get rid of
the `flags` attribute, as it will only confuse debugging.
We no longer set message.flags in the local echo path.
In the markdown parsing step, we just set message.mentioned
directly.
And then we change `insert_new_messages` to no longer
convert flags to booleans, and move that code to only
happen for incoming server message events.
We want to call `set_message_booleans` as soon as we
get data from the server, to avoid confusion about whether
`flags` is the authoritative field.
This commit has callers to `add_message_metadata` call
`set_message_booleans`.
This also sets us up to **not** call `set_message_booleans`
in the local echo codepath, where we can just have the
markdown processor set booleans natively.
In all cases the value of `flags` we were passing in was
actually `message.flags` (although it was slightly obscured in
one place), so now we just pass in `message`.
(We also move a tiny bit of defensive code to set `flags`
into `set_message_booleans`.)
In the JS code, we now use `message.unread` universally as
the indicator of whether a message is unread, rather than
the `message.flags` array that gets passed down to us
from the server.
In particular, we use the unread flag for filtering when
you search.
A lot of this commit is just removing logic to add/remove
"read" from `message.flags` and updating tests.
We also explicitly set `message.unread` to `false` inside of
`unread.mark_as_read()` and no longer have `unread.set_flag()`.
(Some of the callers to `unread.set_flag` were also calling
`unread.mark_as_read`, which was updating the `message`
object, so now we just have `unread.mark_as_read` update
the `message` object. And then unread_ops.mark_all_as_read()
was already calling unread.declare_bankruptcy().)
This adds two similar functions to simplify
our batch processing of unread messages.
unread.get_unread_messages
unread.get_unread_message_ids
They are used to simplify two functions that loop
over messages. Before this change, the functions
would short circuit the loop to ignore messages
that were already read; now they just use the
helpers before the loop.
We now make direct calls to `send_flags_update` for
seting collapsed/uncollapsed, rather than going through
the `batched_updaters` mechanism.
Also the methods in `message_flags` to set
collapsed/uncollapsed now take a single message.
We now do all of the main logic for starring/unstarring
a message in `message_flags.toggle_starred`:
* mark the message as read (just in case)
* update the UI (i.e. the green star in the message)
* update the server
The calling code in both the click handler and the hotkey
handler remains simple--they just handle minor details like
finding the message and clearing popovers.
For updating the server, we now call the new
`send_flag_update` helper.
And we continue to delegate some of the logic to
`ui.update_starred`, but we remove some code there that's
now pushed up to `message_flags.toggle_starred`.
This change should be mostly transparent to users, but it
does remove some inconsistent behaviors between the click
handler and the hotkey handler. Before this change, the
click handler was more aggressive about updating the UI
and marking the message as read. For people using the "*"
key to star/unstar, they probably would only have noticed
different behavior on a slow connection or in an edge
case scenario where only half of the message was onscreen.
More importantly, by simplifying how we talk to the server,
this eliminated up to a one-second lag due to the debounce
logic in the batch_updater code. The complicated debounce
logic is only really needed for batch-updating "read"
messages, and it was overkill and sluggish for starring
messages.
Last but not least, we add defensive code for the local
echo case. (Users have to wait till the message gets acked
to star it.)
Wait until the server acks a message before we enable
the message popover menu. This prevents a whole class
of bugs related to re-drawing the message and changing
the message id, and it also makes room for a little
spinner in the future.
Users with decent internet connections will generally
get server responses before they can click on the
chevron or hit esc/i, anyway.
Trying to collapse a locally echoed message is a rare
thing to do, and it was buggy before this due to races
between the server acking the original message and the
user flipping the collapsed flag.
We now calculate `should_display_collapse` and
`should_display_uncollapse` in the JS code and simplify
the template by eliminating all the inline if/else
logic.
(Note that we are about to disable the message menu
altogether for locally echoed messages, so this change
is partly future-proofing for when we put the menu
back for more innocuous commands.)
Adds type "embedded bot" to bot creation menu. Lets
users select a bot to run from a list of bots.
Currently, this list is hard-coded into the backend.
This is just a basic Dropbox webhook integration. It just
notifies a user when something has changed, it does not
specify what changed. Doing so would require storing data,
as Dropbox API was created mainly for file managers, not
integrations like this.
Closes#5672
The function should execute initially and return a function, not
be a function that when executed returns another function. This
fixes an existing bug.
Currently, users are warned when mentioning @all and @everyone, but not
when posting on the #announce stream. Confirm with users that they want
to send their message on #announce if over 60 people are going to be
notified.
Fixes#6928.
We should move to a design that doesn't require so many success messages,
since each one carries translation risk (e.g. what if the translation is too
long/overflows, or is not a clear translation, etc.). But doing a quick fix
until then.
Previosly, a pointer cursor would display when hovering over some of the
headings in the API docs, however nothing would happen when clicked.
Fixes#7702.
This commit ensures that size of each graph is the same before and
after the data is loaded. It also adds a loading indicator to each
graph until the data is loaded.
Fixes https://github.com/zulip/zulip/issues/6490
This applies the same overflow changes to “.message-info-popover” by
imposing a max width on the popover (so it doesn’t increase in width
when it gets larger) and adding the tooltip on hover.
Adds a markdown preprocessor that finds ordered lists where all items
use the same number and change them to be in normal increasing order,
starting with that number.
Fixes#5159.
This reverts commit eb2bdb706 "sidebar: Narrow to latest topic if
not in stream." On a trial deploy, many users were surprised and
preferred the old behavior.
This reverts commit aebf63c28 "sidebars: Change to more muted
hover/active colors."
In addition to the effects described in its commit message, this
commit gave the unread counts in the left sidebar a much lighter
background, making them harder to see. I'm not quite sure which part
of this change caused that effect how; reverting for now and we
can sort out a new version of the change.
Audible notifications is a confusing term, especially since it could
plausibly mean audible notifications on your phone.
Mobile push notifications is also not great, since most people don't know
what push notifications are.
I removed "receive" from stream settings strings since I think it isn't
necessary, and so that the strings (and translations) would be the same as
what's on the settings pages.
This fixes compose.test_video_link_compose_clicked to just
use a stub for compose_ui.insert_syntax_and_focus.
It also adds direct tests for compose_ui.insert_syntax_and_focus.
Fixes#6362
We now narrow to the latest topic in stream if we are narrowing from
outside the stream, and show all topics grouped together (previous
default) if we are already narrowed to the stream.
Fixes#7555.
This removes the underlines on the stream names and user names when
hovered over for a cleaner look. This is acceptable due to the fact
that hover is signified already by a light grey background.
This was accidentally changed due to an inheritance problem of
`.typeahead.dropdown-menu a` overriding the default bootstrap
selector `.dropdown-menu .active > a` with its color styling
preferences.
This removes the width attribute that actually makes the notification
about a pixel too long, because removing this with a block element will
automatically make it 100% auto fit.
This makes all the alerts in the compose box compatible with dark mode
by choosing different colors and fixing borders to be properly
pronounced, along with removing text shadows that make text unreadable.
On the warning that occurs when you are cross posting to a different
stream, move the “x” to be vertically centered and horizontally aligned
with the”x” on other warnings in the compose box.
This makes the bankruptcy modal compatible with dark mode by adding the
`.modal-bg` class to switch it to dark mode, and by setting a darker
background and border color to the modal header.
This fixes and adds to the logic in commit `525e8e3`. That commit
would only have the stream be the correct color if it was active,
but really it should be dark text by default regardless of whether
it is the active tab bar list item.
This makes the typeaheads dark-mode compatible by changing to the
background to be dark and the text to inherit from the body text
(rather than bootstrap’s default of #333).
Greg Price
synicalsyntax
Rishi Gupta
Roman Godov
Brock Whittaker
Umair Khan
VishalCR7
Tim Abbott
ihsavru
Shubham Dhama
Robert Hönig
YJDave
Balaji2198
Privisus
akashnimare
Logan Williams
aedorado
Aditya Bansal
Harshit Bansal
Vishwesh Jainkuniya
Jerry Zhang
Weronika Grzybowska
rht
Tarun Kumar
Sampriti Panda
infinitelooped
Ricky
fredfishgames
Shreyansh Dwivedi
Steve Howell
Rohitt Vashishtha
Viraat Chandra
Angelika Serwa
Xavier Cooney
Andy Perez
Alena Volkova
Aastha Gupta
Utkarsh Patil
Abhijeet Kaur
Vishnu Ks
Marco Burstein
snlkapil
Utkarsh Patil
civilnewsnetwork
Andy Perez
pradeepgangwar
cPhost
Rhea Parekh
ryan
Akash Nimare
cPhost
