On a 2 GiB, 1 CPU system, webpack would hit the Node.js heap
limit (which is half of physical memory up to 4 GiB, on 64-bit
systems).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We refactor the code for user notification settings and realm-level
defaults of notification settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as separate
variables.
We refactor the code for user display settings and realm-level
defaults of display settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as
separate variables.
This commit changes the code to use container id in the
selector of the status element of presence_enabled setting
such that the correct element is selected because we will
add another element with same class in the realm-level
presence_enabled setting.
Send update event to client after a stream is made web public.
This has been documented in the API documentation since feature level
73; previously the value was always false.
We allow clients to make existing streams web public via the API.
This feature is still disabled via settings in production
environments, because we may have additional policy rules or UI
warnings we wish to add to this sort of conversion.
User can now create web public stream via the /subscribe API.
So, when a web public stream present in the API request does not
exist, it will be created now by specifying the is_web_public
parameter. The parameter would have been ignored without this
commit.
The new error message is more clear about why, "User cannot create
stream with this settings." was bad English, and in any case removing
an unnecessary string is always an improvement for translators.
This new setting both serves as a guard to allow us to merge API
support for web public streams to main before we're ready for this
feature to be available on Zulip Cloud, and also long term will
protect self-hosted servers from accidentally enabling web-public
streams (which could be a scary possibility for the administrators of
a corporate Zulip server).
This is a prep-commit which simplifies changes when we add
web public streams condition here. Since our linter forces us
use switch then, we use it beforehand to simplify changes.
Recently, we discovered that our settings_tab/relative Markdown
directives didn't work when they were in a macro that was included
in another Markdown file. Note that without this commit, the
/help/create-your-organization-profile page is broken. This commit
changes the respective priorities of these two extensions such that
these directives are rendered *after* the macro is included in
another file.
Thanks to Alya Abbott for reporting this bug!
All of our custom Markdown extensions have priorities that govern
the order in which the preprocessors will be run. It is more
convenient to have these all in one file so that you can easily
discern the order at first glance.
Thanks to Alya Abbott for reporting the bug that led to this
refactoring!
gitlint has a bunch of pinned requirements that hold back important
upgrades and conflict with other packages’ requirements. The gitlint
author has rejected proposals to unpin them because it might increase
the amount of maintenance he needs to do
(https://github.com/jorisroovers/gitlint/pull/133). That decision is
his to make, but _somebody_ needs to do the maintenance, so we
delegate it to Debian and Ubuntu. If that means using a significantly
older version of gitlint, that’s a tradeoff we need to make to keep
the rest of our requirements current.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The semgrep --dangerously-allow-arbitrary-code-execution-from-rules
flag is deprecated and no longer used.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is a follow-up to #19388.
We will in the future allow patch requests to change the visibility
of an existing topic, so `last_updated` is better name for this field.
This commit does not affect the API or events in any way, but only the
database.