Previously, when no parameter was passed to the get_timestamp_for_
flatpickr method, it would result in an uncaught exception. This is
breaking the "Add global time" of compose bar.
This can be avoided by doing an early return of current time to hour
in case no string is passed.
This will require customers to include an address when setting
up, or updating, the credit card information for their account.
The billing address for the card will also be saved as the
billing address for the stripe customer object.
The customer object billing address appears on the invoices
that are generated by stripe.
This was introduced in #28767 with the intention to skip scrolling
the selected message.
So, the actual bug that the PR fixed would have been just fixed
by opening the compose box early.
This matches the algorithm that we designed for the Python API, except
that we use a ratio of 2 rather than sqrt(2) in the message_fetch code
path, because it's a heavier request.
We increase the number of failures before showing a user-facing error
to roughly preserve the same time period before a user-facing error is
shown.
Previously, these endpoints just did exponential backoff, without
looking at the rate-limiting headers returned by the server, resulting
in requests that the client could have been certain would fail with an
additional rate-limiting error.
Fix this by using the maximum of the existing exponential backoff with
the value returned by the rate-limiting header.
Fixes#28807.
This should help reduce the risk of hitting rate limits when users
have a very large number of messages to fetch via this mechanism.
Inline the `messages` variable that was only used in one place while
we're touching this.
This function incorrectly and misleadingly did an immediate initial
call, despite both of its callers doing immediate calls themselves (in
one case, with a different parameter passed).
This led to unnecessary server load when reloading the app via event
system triggered reloads, since every client would call `/` twice.
I was not able to reproduce obviously badly broken behavior from these
logic bugs, but after the renaming of message_viewport helpers in the
last few commits, it's clear that this logic was trying to check if
we're actually at the start/end of the possibly message feed, not just
the rendered portion, and doing so incorrectly.
The previous logic for both scrolling down and using pagedown would
incorrectly mark an entire conversation as read when reaching the
bottom of a render window, even if there were more messages loaded or
to fetch from the server.
Fix this error in the calculation by asking the correct data
structures if we're actually at the bottom.
To avoid the navigate.js keyboard shortcut code paths circumventing
this new logic, or needing to duplicate it, they now call
process_visible, rather than its helper.
Since we always call `deactivate` from `hashchange`,
`browser_history.state.changing_hash` is always `true` and hence
`save_narrow` just retuns without doing anything.
572443edc6 removed the callsite that triggered the exec in
`zulip::systemd_daemon_reload`, making its inclusion and ordering via
`require` moot.
Remove the call.
The endpoint was lacking validation that the authentication_methods dict
submitted by the user made sense. So e.g. it allowed submitting a
nonsense key like NoSuchBackend or modifying the realm's configured
authentication methods for a backend that's not enabled on the server,
which should not be allowed.
Both were ultimately harmless, because:
1. Submitting NoSuchBackend would luckily just trigger a KeyError inside
the transaction.atomic() block in do_set_realm_authentication_methods
so it would actually roll back the database changes it was trying to
make. So this couldn't actually create some weird
RealmAuthenticationMethod entries.
2. Silently enabling or disabling e.g. GitHub for a realm when GitHub
isn't enabled on the server doesn't really change anything. And this
action is only available to the realm's admins to begin with, so
there's no attack vector here.
test_supported_backends_only_updated wasn't actually testing anything,
because the state it was asserting:
```
self.assertFalse(github_auth_enabled(realm))
self.assertTrue(dev_auth_enabled(realm))
self.assertFalse(password_auth_enabled(realm))
```
matched the desired state submitted to the API...
```
result = self.client_patch(
"/json/realm",
{
"authentication_methods": orjson.dumps(
{"Email": False, "Dev": True, "GitHub": False}
).decode()
},
)
```
so we just replace it with a new test that tests the param validation.
This should give some more room for systems that are still below 4GB
of RAM to use the lower-memory multithreaded mode, which is less
likely to have OOM kills (a very bad experience).
There should be little cost, as few systems are likely allocated with
memory in this range.
Anders Kaseorg
roanster007
Alex Vandiver
Aman Agrawal
Lauryn Menard
Tim Abbott
Mateusz Mandera