The fix_positions argument here fixes the horizontal
position of the stream popover.
It also fixes the vertical position, both in the default case, and
also doing an appropriate adjustment for the case that the color
picker is open.
This contains a few changes by tabbott to, rather than hiding the
arrow unconditionally, only do so when it would no longer point at the
right part of the screen.
Fixes#2374.
Fixes#6059.
Fixes#7290.
We use the `fix_positions` options every time
we launch a user popover, whether it is from
the message pane avatar or the buddy list
chevron.
For the message pane case, we can eliminate
some complexity related to trying to put
the menu above or below the avatar. We now
always suggest "right", and if there are
constraints due to being close to the edge
of the screen, the fix_positions code
will take care of it.
The patch to bootstrap will make the position smarter, but we still
want to preserve the 100px default vertical offset we chose for visual
reasons.
Tweaked by tabbott to preserve the visual design.
Changed <h5> to <p>, and removed the special formatting of
.empty_search_text to make this more in line with the formatting we
generally use with empty narrows.
Since da8f4bc0e back in August, this control flow has caused
`flags.active_mobile_push_notification` to be cleared if we don't send
these `remove` messages at all, and if we send them directly to GCM...
but not if we send them via the Zulip notification bouncer.
As a result, on a server configured to send `remove` notification-messages
via the bouncer, we accumulate "active" messages and never clear them.
If the user then does `mark_all_as_read`, we end up sending a `remove`
for each of those messages again, and all in one giant burst. We've
seen puzzling bursts of hundreds of removals pass through the bouncer
since turning on removals on chat.zulip.org; it's likely many of them
are caused by this bug.
This issue was made more acute with f4478aad5, which unconditionally
enabled removals.
Test added by tabbott.
This removes the left border extending the stream label from the
recipient bar in from the drafts in drafts modal. Those borders are
important in the message feed for containing several messages, but
here we're only ever going to show individual drafts, and this change
avoids potential color clashes with the blue box surrounding the
recipient blocks.
This removes the change in background to a darker one for active draft,
also removes the change in recipient_row_date color to blue; adds a blue
border around the draft box.
Since the bootstrap popovers are destroyed asynchronously so opening a
emoji popover in quick succession like by clicking the reaction button
on another message was causing a race condition which was causing some
operations to be applied on a destroyed emoji popover. This commit
fixes it by making sure to apply any operations only to the currently
active popover.
Fixes: #9851.
I'm torn about this, since there is good content here. But ultimately I think
* This page is a lot of work to write and maintain.
* In most cases, the right thing is for people to find the page that
explains the full feature. E.g. if you don't know what an "administrator"
is, the page I hope you find is "Roles and Permissions". For bots, it's
"Bots and Integrations". Writing a punchy short summary for a glossary
that does better than that is possible, but not fast.
* People find things via search, e.g. by Googling "What is X in Zulip",
rather than looking for a glossary.
* This page was written more than 3 years ago, before we had 100+ help
articles. So it may have served a purpose in the past that no longer
exists.
Adds three helper functions - `row_with_focus`, `row_before_focus` and
`row_after_focus` to get the focused, previous and next to focused
draft rows respectively.
`delete_id` in `drafts.js` referred to the next draft row which was
to be focused when deleting using hot keys. The var name was absurd
and is hence renamed.
Adds a `remove_draft` function which deletes the draft and updates the ui
by removing it from the list of drafts.
Also adds comments to increase readability.
Show "sent to different narrow" notification and other such notification by
notifications.notify_local_mixes for non locally echoed message sent by
current client.
With significant new comments added by tabbott.
Fixes: #11488.
Previously, this was only available in the Zulip development
environment.
Further work is needed on documenting this and how to use it for
managing work to follow up on.
This is the only server-side change required for the FCM migration!
Optionally, at some point in the future we might choose to migrate
to the new ("v1") API which FCM also offers. Nothing revolutionary
but there are some nice things about it:
https://firebase.google.com/docs/cloud-messaging/migrate-v1
The client-side fix to make these not a problem was in release
16.2.96, of 2018-08-22. We've been sending them from the
development community server chat.zulip.org since 2018-11-29.
We started forcing clients to upgrade with commit fb7bfbe9a,
deployed 2018-12-05 to zulipchat.com.
(The mobile app unconditionally makes a request to a route on
zulipchat.com to check for this kind of forced upgrade, so that
applies to mobile users of any Zulip server.)
So at this point it's long past safe for us to unconditionally
send these. Hardwire the old `SEND_REMOVE_PUSH_NOTIFICATIONS`
setting to True, and simplify it out.
After clicking on checkbox saying "Show text only version" UI was rendered
correctly but after refreshing page keeping checkbox checked, emails were
shown without "text only version" but checkbox value remained checked.
Now after refreshing page checkbox value changes to its default value.
For users putting Zulip behind certain proxies (and potentially some
third-party API clients), buffer sizes can exceed the uwsgi default of
4096. Since we aren't doing such high-throughput APIs that a small
buffer size is valuable, we should just raise this for everyone.