We use this function to show who's typing in the
direct messages narrow.
Renamed it because, with the addition of stream typists to
`typist_dct` in the next commit, this might be confusing.
This commit addresses the discussed issue by renaming
'get_all_typists()' to 'get_all_direct_message_typists'.
Correct the `PUT` to `POST` in the
`/docs/tutorial/life-of-a-request.md` to match it with the actual code
in `zproject/urls.py` route: '/users'. (The HTTP method changed at
some point).
Tested by tabbott using:
curl -v -X HEAD https://chat.zulip.org/api/v1/users
This fixes the explanation of the setting's syntax to be more precise
(which doesn't mean "easily understandable" - because the setting is
a bit tricky) as well as an example to illustrate it.
The deleted CSS around the `.zulip-icon-ellipsis-v-solid` class
has no impact on the hover controls, as flexbox and grid are
handling baseline alignment, not this one-off line-height.
While an en dash--as replaced here with a hyphen--is sounder
typographically, the other ranges in the file use a hyphen, which
is arguably also more interoperable in a plain-text file such as
this (though other en dashes live on in the file, as part of the
original licensing text).
This makes all shortened forms of "incorporated" uniform across
the file, and matches how "Twitter, Inc." is presented in the files
in question, e.g., atop `web/third/bootstrap/js/bootstrap.js`.
Updates the main description of the `api/set-typing-status` endpoint
for the new fields in the register response for the typing start,
stop, expired time intervals. Previously these were hardcoded by
the client side code and not the server side code.
Also updates the developer documentation for typing indicators in
the subsystems docs. This refreshes a few parts of that doc that
were already out of date, as well as adds the information about
the new register response fields noted above.
Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.
But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to. Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.
Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.
This also means we no longer need to update this page as old releases
age and that value advances.
Also fix a typo, and cut the reference to working degraded on
older releases. Starting earlier this year we finally started
hard-refusing such connections:
https://github.com/zulip/zulip-mobile/issues/5102https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)
Tweaked provision script to run successfully in Fedora 38 and
included a script to build the groonga libs from source because
the packages in Fedora repos are outdated.
There is a major version jump from the last supported version (F34)
which is EOL so references and support for older versions were
removed.
Fixes: #20635
Almost all users of JsonSuccessBase seem to also include
SuccessDescription. /server_settings used a different description from
the rest of the JsonSuccessBase users, but the difference is small
enough that using the generic description of the former
SuccessDescription is fine.
The "followup_day2" email template name is not clear or descriptive
about the purpose of the email. Creates a duplicate of those email
template files with the template name "zulip_onboarding_topics".
Because any existing scheduled emails that use the "followup_day2"
templates will need to be updated before the current templates can
be removed, we don't do a simple file rename here.
We have historically cached two types of values
on a per-request basis inside of memory:
* linkifiers
* display recipients
Both of these caches were hand-written, and they
both actually cache values that are also in memcached,
so the per-request cache essentially only saves us
from a few memcached hits.
I think the linkifier per-request cache is a necessary
evil. It's an important part of message rendering, and
it's not super easy to structure the code to just get
a single value up front and pass it down the stack.
I'm not so sure we even need the display recipient
per-request cache any more, as we are generally pretty
smart now about hydrating recipient data in terms of
how the code is organized. But I haven't done thorough
research on that hypotheseis.
Fortunately, it's not rocket science to just write
a glorified memoize decorator and tie it into key
places in the code:
* middleware
* tests (e.g. asserting db counts)
* queue processors
That's what I did in this commit.
This commit definitely reduces the amount of code
to maintain. I think it also gets us closer to
possibly phasing out this whole technique, but that
effort is beyond the scope of this PR. We could
add some instrumentation to the decorator to see
how often we get a non-trivial number of saved
round trips to memcached.
Note that when we flush linkifiers, we just use
a big hammer and flush the entire per-request
cache for linkifiers, since there is only ever
one realm in the cache.
nginx sets the value of the `$http_host` variable to the empty string
when using http/3, as there is technically no `Host:` header sent:
https://github.com/nginx-quic/nginx-quic/issues/3
Users with a browser that support http/3 will send their first request
to nginx with http/2, and get an expected HTTP 200 -- but any
subsequent requests will fail with am HTTP 400, since the browser will
have upgraded to http/3, which has an empty `Host` header, which Zulip
rejects.
Switch to the `$host` variable, which works for all HTTP versions.
Co-authored-by: Alex Vandiver <alexmv@zulip.com>
This commit encompasses the following changes:
* Replace the [More...] link with a button titled "Show more".
* Replace the [Show Less...] link with a button titled "Show less".
* Add various on-hover interactions to the buttons.
* In the condensed view, add fading to the bottom of the message to
visually communicate that the message is truncated.
* Update /help/ description.
Fixes#22801.
Co-authored-by: Evy Kassirer <evy.kassirer@gmail.com>
Restore the default django.utils.log.AdminEmailHandler when
ERROR_REPORTING is enabled. Those with more sophisticated needs can
turn it off and use Sentry or a Sentry-compatible system.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Uploads are well-positioned to use S3's "intelligent tiering" storage
class. Add a setting to let uploaded files to declare their desired
storage class at upload time, and document how to move existing files
to the same storage class.
Dinesh
Anders Kaseorg
Tim Abbott
Simon Michalke
Moazzam Moriani
ecxtacy
xpufx
Arnold Mwesigye
Mateusz Mandera
Karl Stolley
David Rosa
Alex Vandiver
Lauryn Menard
Greg Price
shu.chen
bjorn3
Steve Howell
Sahil Batra
n0099
Ishita Gupta