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.
The width of the messages div is set to 600px, while the
digest-email-container can be 500px at the most. Increasing the width
of the digest-email-container makes the /digest slightly more
readable.
The padding changes move the number a bit to the right and down, towards
where the bottom right corner of an unread count box would have been. This
makes the number look better aligned with the unread count boxes above it.
We've for a while had logic to set plan_type to LIMITED when importing
into Zulip Cloud; we need corresponding logic to set it to SELF_HOSTED
when importing into a self-hosted server.
Fixes#11541.
We swallow the error if our python_to_js_filter code is
unable to parse some python regex properly. This ensures
that the web app stays responsive.
We would fail to show an accurate local echo for these
regexes, however, the backend would act as the final
authority for handling the realm pattern conversion.
Since on replacing the first 'P<>' group, we remove this text from
the string, we have to make the RegExp start looking from index 0
again to properly convert later 'P<>' groups to JS regex syntax.
For Google auth, the multiuse invite key should be stored in the
csrf_state sent to google along with other values like is_signup,
mobile_flow_otp.
For social auth, the multiuse invite key should be passed as params to
the social-auth backend. The passing of the key is handled by
social_auth pipeline and made available to us when the auth is
completed.
For internal stream messages, most of the time, we have access to
a Stream object. For the few corner cases where we don't, it is a
much cleaner approach to have a separate function that accepts a
stream name than having one multi-option helper that accepts both
names and objects.
It looked kinda terrible in between the two
user lists.
There is some discussion here (I have to break the
link into two lines to make gitlint happy):
https://chat.zulip.org/#narrow/stream/
101-design/topic/user.20sidebar.20in.20left/near/697682
We want the search widget, when visible, to be
outside the scroll container for the stream list.
One obvious use case is if you start scrolling, and
then realize it might be less effort to search.
Also, for user search, it already worked this way.
We have to add a couple resizing hooks here, but
it's not necessary to change the actual resize
calculation, since we move the section inside
of #streams_header, which is already accounted
for.
The only markup change here is to add
a `stream_search_section` class. I don't
know why we use `notdisplayed` here instead of
jQuery, or what `input-append` is for, but I
considered them outside the scope of this change.
We can also remove some crufty CSS that was
compensating for it being inside the container.
The bot's details (such as ID and name) are used to format a
connection label in Zapier's UI. This allows users to distinguish
between different Zapier-to-Zulip connections set up with different
bots.
First, we are not removing Group PMs from the
right sidebar, where most people see it.
There is a setting called:
[ ] User list in left sidebar in narrow windows
There are probably very few people that turn that on,
and even when they do, the setting only takes effect
when your window is less than a certain width.
This feature bitrots very quickly, because very few
core maintainers use it.
It's already kind of broken. It gets very crowded,
and we get CSS bugs when we move the right sidebar
into the left sidebar. (We can fix those bugs, but
they crop up unexpectedly due to the nature of CSS.)
We historically tried to maintain a ratio between
stream list, single-user buddy list, and group-user
buddy list, but the group-user buddy list gets
particularly crowded out, and it's basically useless
now.
We want to revisit the entire feature eventually, but
this commit at least gives the normal buddy list some
breathing room.
Also, if you need to see the info in the group PM
list, you can basically expand "Private Messages" to
see your recent group PM conversations. And if you
want to see who's actually online, that info is
already implicit from the normal buddy list.
If users have the option to put user lists in
the left sidebar for narrow windows, they will
now get 15px more of real estate in the left
sidebar.
I just removed the `-15` fudge factor.
We were double-counting the keyboard icon's
margin (8px) when figuring out how much room
we had for the two users lists.
Now we just use the safe outer height of
the anchor tag.