The `en_US.UTF-8` locale may not be configured or generated on all
installs; it also requires that the `locales` package be installed.
If users generate the `en_US.UTF-8` locale without adding it to the
permanent set of system locales, the generated `en_US.UTF-8` stops
working when the `locales` package is updated.
Switch to using `C.UTF-8` in all cases, which is guaranteed to be
installed.
Fixes#15819.
This will stop dropping events in the case that the background
`maybe_send_batched_email` thread takes longer than 30s. However, see
also #15280 and the TODO comment about how we lose events upon
restart; this worker is still lossy.
The 'reply' button shows the stream>topic or recipient(s) of the
selected message, for better UX. It also expands to fill the
remaining horizontal space in the button bar -- this should help make
it easier for new users to figure out how to reply.
Finally, it uses "Message" instead of "Reply", to better match the
compose box.
Fixes#17940.
In puppet, we use pgrep in the collection stage, to see if rabbitmq is
running. Sufficiently bare-bones systems will not have
`procps` (which provides `pgrep`) installed yet, which makes the
install abort when running `puppet` for the first time.
Just installing the `procps` package in Puppet is insufficient,
because the check in the `unless` block runs when Puppet is
determining which resources it needs to instantiate, and in what
order; any package installation has yet to happen. As
`erlang-base` (which provides `epmd`) happens to have a dependency of
`procps`, any system without `pgrep` will also not have `epmd`
installed or running. Regardless, it is safe to run `epmd -daemon`
even if one is already running, as the comment above notes.
Using `pgrep -f epmd` to determine if `empd` is running is a race
condition with itself, since the pgrep is attempting to match the
"full process name" and its own full process name contains "epmd".
This leads to epmd not being started when it should be, which in turn
leads to rabbitmq-server failing to start.
Use the standard trick for this, namely a one-character character
class, to prevent self-matching.
Followup of #17926.
Basically, the aim is to concise modal texts
to use 'Confirm' instead of long labels since they can
tricky for translators and can also create bad strings
having long words.
Earlier, a user can only mute a topic from its recipient bar but can't
unmute it from there (and in fact we displayed an option to mute even
if the topic was already muted!). This commit fixes that bug and
allows a user also to unmute the topic from its recipient bar.
There are two core issues here;
* We did not have code, an icon, etc. for the "already muted" case in
the recipient bar logic at all.
* We did not rerender messages in !excludes_muted_topics views when
muting state changed.
See: 660475bd0c for background on when
we started only rerendering the streams with excludes_muted_topics
after muting changes. Rerendering of newly muted topics are important
for live rendering if a user is narrowed to that topic itself, which
are essentially all excludes_muted_topics narrows anyway.
Hence, now, we rerender by calling the `rerender` function for muted
topics (which is done just before we update the items for muting via
the function: `update_items_for_topic_muting`).
Tweaked by tabbott to add comments explaining the reasoning and
long-term plans.
Fixes#15223.
We are restricting the feedback widget (confirmation pop-up)
to be visible to the users if they have muted the topic using
the hotkey: `M`, because if the users have muted the topic in
some other way then it is known to them about their activity.
In fact, the confirmation pop-up was intrusive to some users
(see #2367).
While using the hotkey they can unknowingly mute the topic. Hence, in
such a case, it is necessary to acknowledge the users about their
action.
This commit modifies the test_wildcard_mention_restrictions test
for checking that moderators are not allowed to send messages
with wildcard mention if wildcard_mention_policy is set to
WILDCARD_MENTION_POLICY_ADMINS. Previously, we were checking
for members, but it is better to check for moderators.
This test was wrong, in that it checked for the English status string
when the current language was expected to be German; this happened to
work until now because with i18next we were failing to include the
string in question in our translation data; and early today I did the
first translation data sync since our translators had translated that
string for German.
Apparently, after upgrading to Django 3.2, mutating is_staff and then
saving can result in a user's session being destroyed.
In any case, this test is probably better written using two different
users with the different roles, which we have in our initial database
anyway.
In Django 3.2 slugify strips trailing dashes and underscores:
0382ecfe02
sanitize_name doesn't so this difference should be documented like the
others.
Underscore character is already covered by \w, so _ in the regex is
redundant. Also the docstring is mildly incorrect - underscore already
is an allowed character by django's slugify (and always was) for the
aforementioned reason.
This is a straightforward upgrade in terms of changes needed.
Necessary changes were:
- Set `DEFAULT_AUTO_FIELD`
https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-auto-created-primary-keys
- `The default_app_config application configuration variable is deprecated, due
to the now automatic AppConfig discovery.`
https://docs.djangoproject.com/en/3.2/releases/3.2/#automatic-appconfig-discovery
To handle this one, we can remove default_app_config from
zerver/__init__.py because it satisfies what release notes describe in
https://docs.djangoproject.com/en/3.2/releases/3.2/#automatic-appconfig-discovery:
"Most pluggable applications define an AppConfig subclass in an apps.py
submodule. Many define a default_app_config variable pointing to this
class in their __init__.py. When the apps.py submodule exists and
defines a single AppConfig subclass, Django now uses that configuration
automatically, so you can remove default_app_config."
An important note is that rebuild-test-database needs to be run after
this upgrade in dev environment - if tests are run with test db that was
built on the previous version, they will fail due to a mysterious bug
(?), where changing attributes of a user and .save()ing after logging in
in the test via self.login_user, causes getting logged out - the next
requests via self.client_get etc. are unauthed for some reason,
unless self.login_user is called again. This behavior is no longer
exhibited upon rebuilding the test db - and I can't reproduce it in
production or dev db. So this can likely be reasonably dismissed as some
quirk of the test client system that won't be relevant in the future and
doesn't impact production.
Since we don't have content for GIPHY popover at the time
popover is rendered, we need to render with some fake
content otherwise popover library doesn't allows for us
to show the popover.
This came into notice after 5adc6d7297
broke show popover behaviour for GIPHY but didn't break it for
emoji popover as emoji popover already renders with some content.
Prior to this commit, popover library used `title` as content for
GIPHY popover.
In some cases, puppet can end up restarting supervisord services - which
will use code from the old deployment, because when puppet runs,
/home/zulip/deployments/current still points there. Thus restart-server
needs to be used in favor of start-server, unless we know that puppet
has been skipped.
Now that we are passing source realm's id instead of string_id in
source realm selector, it makes sense to rename the "source_realm" field
to "source_realm_id".
In the source realm selector, when we select a realm from which we want
to import the data, we pass the source realm's string_id. The problem
with this approach is that the string_id can be an empty string. This
commit makes the source_realm pass the realm's id instead of string_id.
Now, the source_realm's value will either be an integer or "" (empty
string) when we don't want to import settings from any realm.
This commit fixes the following help pages -
- configure-who-can-create-a-stream.md to use "Stream permissions"
subsection and not "Other permissions".
- configure-who-can-invite-to-streams.md to use "Stream permissions"
subsection and not "Other permissions".
- restrict-wildcard-mentions.md to use "Stream permissions" subsection
and not "Organization permissions".
- restrict-bot-creation.md to use "Other permissions" subsection and
not "Organization permissions".
- restrict-visibility-of-email-addresses.md to use "User identity"
subsection and not "Organization permissions".
This commit fixes invite-new-users.md to show all the options of who
can invite under "Are invitations required for joining the organization?"
and makes this page similar to help pages for other policies.
This commit updates restrict-permissions-of-new-members.md
to add "inviting users to organization" in the list of actions
that can be restricted for new members.
We also fix the subsection of waiting_period_threshold to be
"Joining the organization".
* Add mobile app instructions for interacting with them.
* Fix inconsistent headings.
* Document the new state that starred message counts are the deafult,
and mention the "come back to" workflow for them.
Previous versions of zulip used `nvm alias default ...` to have `nvm`
prepend the full path to the latest `node` install to the `PATH` in
root's shell. Unfortunately, this means that `update-prod-static`,
when called from `upgrade-zulip-stage-2` after an upgrade of node in
`install-node`, would still have the full path to the _old_ `node` at
the start of its PATH, because the PATH of `upgrade-zulip-stage-2`
would still be unchanged.
Bootstrap out of this by setting a known-reasonable PATH during
upgrade, and remove the problematic `nvm alias default` behaviour.
Fixes#18258.
In Debian, becoming root as `su` does not alter the `$PATH`; this can
lead to the root user not having `/usr/sbin` in its path, and thus
the `useradd zulip` step of the installer fails.
Fixes#17441.
Currently only enabled in development, since the exact details don't
seem right..
Co-Author-By: Signior-X <b19188@students.iitmandi.ac.in>
Co-Author-By: Aman Agrawal <amanagr@zulip.com>
Implements UI for #8005.
Instead of taking the "onion" approach, where all services are
stopped, and then started back up again, default to a rolling restart
across all processes. This draws out how long the overall "restart"
takes, but minimizes the time that any of the services are down. This
minimizes user-visible impact and queue buildup.
In cases where speed is more important than minimal impact (for
example, there is already a current outage), a --less-graceful flag is
provided, which brings the services down more suddenly, and back up in
a still-correct order.
Commit dc67870 introduced a user confirmation modal before
deleting profile picture, leaving the user documentation
unchanged.
Added a commit to reflect the newly added change within
the user documentation as well.
This avoids slightly glitchy looking behavior in certain scroll
positions where there just isn't enough space above link to make it
look like it's top of the other element.
Alex Vandiver
Tim Abbott
Ken Clary
aryanshridhar
akshatdalton
sahil839
sophie200
Mateusz Mandera
Aman Agrawal
Siddharth Asthana
Anders Kaseorg
mandepsingh
m-e-l-u-h-a-n
pilgrim2308