The value, if unset, defaults to[^1]:
> a size equal to 1/32nd (about 3%) of shared_buffers, but not less
> than 64kB nor more than the size of one WAL segment, typically 16MB
Letting it choose this, by default, but allowing an override via
`zulip.conf`, seems preferable to hard-coding an arbitrary value.
[^1]: https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-BUFFERS
The previous thresholds were set based on the assumption that 50% of
the memory on the host was taken up by Django and friends, leaving
only 50% for the database host.
On separate database hosts, this leads to a too-small default value
for shared_buffers, which is generally suggested to be 25% of your
database-dedicated memory.
Check if there is a `zulip::app_frontend_base` as part of the deploy,
and use that to adjust if we halve `$zulip::common::total_memory_mb`
or not for purposes of calculating PostgreSQL memory settings. We
also provide a `postgresql.memory` override, if necessary.
Both of these handlers immediately hide the banner, so the difference
between .on() and .one() doesn’t matter.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For channel dropdowns in move messages and move topic modals
only subscribed channels are included.
To fix it, a new function is made to include subscribed
and unsubscribed channels to which the acting user has
content access. Each group is sorted respectively with
subscribed channels followed by unsubscribed channels.
To avoid unsubscribed channels from getting included in the
compose box dropdown and saved snippets UI, a separate function
get_stream_for_move_messages_widget is made. This function
is used to include unsubscribed channels in move selector
dropdown only.
Fixes#33670.
This commit:
* Creates a migration to rename any existing Client with
name="populate_db" to "ZulipDataImport".
* Updates populate_db.py to use ZulipDataImport for new
message creation
These changes should make code to identify imported messages
considerably more readable.
Fixes#33909.
Vite introduced allowedHosts config at
https://vite.dev/config/server-options#server-allowedhosts. This caused
our help beta dev server to break in case of dev droplets since it's
hostname is not specified in the allowed lists. Since we have a way to
know our hostname, we do not pass a blanket true for all hostnames in
this case.
Implemented on Zulip Cloud support view only since this information
isn't relevant for self-hosted support actions.
Looking up the realm's currently used upload space adds 3 database
queries to the support view test as there is no RealmCount data for
the upload quota used in the test. And therefore installation_epoch
is called for the realm.
With RealmCount upload quota used data, only 2 additional database
queries would be made for the realm's support view data.
Migrate the demo organization warning that's shown on all the tabs
for organization settings to use the shared banner code.
Updates links in the current warning to be buttons in the banner,
and matches the navbar alert banner for demo organizations.
Fixes#34447.
Since we're no longer adding links to this banner, we don't need
to use "$t_html" when generating the label for the demo organization
warning banner.
Follow-up to #34518.
This follows our usual backporting scheme, occurring e.g.
in #31468. We make the migration depend on the last migration in 10.x,
and create a merge migration to avoid having multiple leafs.
It doesn't make sense that there would be no compose pill user ids
if there were compose pill emails, and there needs to be permission
to send a direct message or the message won't successfully send.
This was working before because `user_ids_string` ended up empty
in `validate_private_message`, which incorrectly returned true
for `check_dm_permissions_and_get_error_string`.
