We encountered the following two new cases with integration bots in
Slack imports:
1. Bots without the image_72 field in their data. Such bots should fall
back to gravatar.
2. Bots whose bot_id is the sender of certain messages, but querying the
bots.info endpoint returns bot_not_found error. We should create
dummy accounts in place of such bots.
Just like in the prior commit we add similar code in `get_subscription`,
here we do this for reactions. If two Slack accounts, which will be
merged into one Zulip account, posted the same emoji reaction to a
message, we need to avoid duplication.
In 1517601e9d we added merging of accounts
with the same email address; but didn't prevent duplication of
subscriptions when two Slack accounts, merged into one Zulip account,
belong to a channel.
This commit updates the formatting of the channel archive and
unarchive notifications to make the channel name bold and clickable.
The channel name is now displayed as a Markdown link with bold
formatting, ensuring it stands out while remaining a clickable link
to the channel.
This commit adds support for unarchiving archived channels
by introducing the `is_archived` parameter to the
`PATCH /streams/{stream_id}` API endpoint. Sending a PATCH
request with `is_archived: false` will unarchive the specified
channel.
This is a cleanup commit to remove the unnecessary 'or'
condition in the 'mark_archived' function. The condition
was redundant, as the same check is already performed by
verifying whether 'sub' is undefined.
Previously, the "generate email" UI was hidden during live-update
when archiving a stream but became visible again on reload. The
pre-commit prevents the UI from being hidden specifically in the
case of archiving and unarchiving a stream.
This code dates back to 57b52310639a; however, this has been handled
by `postgresql-common` adding a post-install trigger to call
`pg_updatedicts` for each new PostgreSQL version, since
`postgresql-common` version 153 (February 2014).
Recent versions of postgresql-common's `pg_upgradecluster`, starting
with version 254, (i.e. on Ubuntu 24.04, but not 22.04) will not just
_suggest_ running the analyze, but will do so automatically. While
somewhat helpful, it always does so with `--analyze-in-stages`, which
as noted in f77bbd3323, is actually the incorrect choice for us.
Passing `--no-start` ensures that `pg_upgradecluster` consistently
does not do any analyzing, allowing us to start the cluster manually
and then perform the analyze correctly ourselves.
This uses the same technique used in 840884ec89, to only apply select
parts of the Puppet configuration. This is more correct, and simpler,
than attempting to chop out some base puppet roles, and hack around
the `purge => true` supervisor.d configuration.
Since c8ec3dfcf6, the file must contain the version that was
configured, or we run `ALTER EXTENSION pgroonga UPDATE`; if the file
is missing, and pgroonga was previously installed, it run `CREATE
EXTENSION pgroonga` which will be an error. If the file is present
but pgroonga was not configured, a later attempt to enable pgroonga
will incorrectly run `ALTER EXTENSION pgroonga UPDATE` instead of
`CREATE EXTENSION pgroonga`.
If the file existed on the previous version, touch it in the new
PostgreSQL version. This will ensure that puppet will *always* run
the pgroonga update, which may be necessary in case the pgroonga
version also changed. At worst, if the pgroonga version has not
changed, this will be a safe no-op.
