Earlier, the URL directed to live API keys. Updated the URL
to direct to 'test API keys'.
Also explicitly mentioned is to double check that the keys are
'test keys', in case Stripe changes the URL as it did before.
The "nothing else" line is accurate at a high level but more ambigious
than I'd like for sensitive documentation -- we're not trying to make
an extreme claim that we've disabled all forms of short-term logging.
This commit replaces the old dev login screenshot with the new one.
This also replaces the default path that we mention in the docs to
localhost:9991/devlogin.
These metadata are essentially all publicily available anyway, and
making uploading them unconditional will simplify some things.
The documentation is not quite accurate in that it claims the server
will upload some metadata that is not actually uploaded yet (but will
by soon). This seems harmless.
The other option would be to run the cron job ourselves, but I feel
like different organizations with different policies might prefer very
different frequencies; daily/hourly, and it's not easy to make that
configurable with a cron file declared in puppet.
Fixes#27866.
The original behavior of this setting was to disable LDAP
authentication for any realms not configured to use it. This was an
arbitrary choice, and its only value was to potentially help catch
typos for users who are lazy about testing their configuration.
Since it makes it a very inconvenient to potentially host multiple
organizations with different LDAP configurations, remove that
behavior.
This makes it possible to send notifications to more than one app ID
from the same server: for example, the main Zulip mobile app and the
new Flutter-based app, which has a separate app ID for use through its
beta period so that it can be installed alongside the existing app.
The word "Filtrar" is ambiguous in this context since it can be
interpreted as "filter out" which is the opposite of what we want
here. "Buscar solo" is a better phrase that we can use unambiguously
and consistently for all instances of "Narrow to".
Updates API and contributor documentation for writing integrations
for the new `generate-integration-url.md` macro. Removes all
refrences to `create-bot-construct-url.md`, which was removed in
the previous commit.
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.
It’s unclear what was supposed to be “safe” about this wrapper. The
hashlib API is fine without it, and we don’t want to encourage further
use of SHA-1.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This includes changing the URL to #settings/preferences, with a
transparent redirect so that existing links, like the one from Welcome
Bot, continue to work.
Users can, quite understandably, assume that upgrading Zulip upgraded
the underlying PostgreSQL version. Though it is mentioned at the top
of the page, mentioning it here clarifies that it is an additional
step.
- Updates instances of "private message", "PM", and "private_message",
excluding historical references in `overview/changelog.md`.
- Also excludes `/docs/translating` since we would need new
translations for "direct messages" and "DMs".
Previously, `X-Forwarded-Proto` did not need to be set, and failure to
set `loadbalancer.ips` would merely result in bad IP-address
rate-limiting and incorrect access logs; after 0935d388f0, however,
failure to do either of those, if Zulip is deployed with `http_only`,
will lead to infinite redirect loops after login. These are
accompanied by a misleading error, from Tornado, of:
Forbidden (Origin checking failed - https://zulip.example.com does not match any trusted origins.): /json/events
This is most common with Docker deployments, where deployments use
another docker container, such as nginx or Traefik, to do SSL
termination. See zulip/docker-zulip#403.
Update the documentation to reinforce that `loadbalancer.ips` also
controls trust of `X-Forwarded-Proto`, and that failure to set it will
cause the application to not function correctly.
- Create a dedicated "Reporting bugs" page to learly document
where and how bugs should be reported.
- Drop "Reporting issues" section from the Contributing guide.
- Delete "Bug report guidelines" page.
04cf68b45e make nginx responsible for downloading (and caching)
files from S3. As noted in that commit, nginx implements its own
non-blocking DNS resolver, since the base syscall is blocking, so
requires an explicit nameserver configuration. That commit used
127.0.0.53, which is provided by systemd-resolved, as the resolver.
However, that service may not always be enabled and running, and may
in fact not even be installed (e.g. on Docker). Switch to parsing
`/etc/resolv.conf` and using the first-provided nameserver. In many
deployments, this will still be `127.0.0.53`, but for others it will
provide a working DNS server which is external to the host.
In the event that a server is misconfigured and has no resolvers in
`/etc/resolv.conf`, it will error out:
```console
Error: Evaluation Error: Error while evaluating a Function Call, No nameservers found in /etc/resolv.conf! Configure one by setting application_server.nameserver in /etc/zulip/zulip.conf (file: /home/zulip/deployments/current/puppet/zulip/manifests/app_frontend_base.pp, line: 76, column: 70) on node example.zulipdev.org
```
Prakhar Pratyush
Alex Vandiver
Anders Kaseorg
Tim Abbott
Aman Agrawal
Divyansh Seth
Karl Stolley
s-bose7
Riken Shah
Mateusz Mandera
David
Greg Price
Alya Abbott
Lauryn Menard
Viktor
Hardik Dharmani
Tam Le
Dinesh
Simon Michalke
Moazzam Moriani
ecxtacy
xpufx
Arnold Mwesigye
shu.chen
bjorn3
Steve Howell
Sahil Batra
n0099
Ishita Gupta
nimish
Matthew Volpe
Zixuan James Li