The `on_success` function within `echo.resend_message` is executed when
the server successfully acknowledges a resent message. In this scenario,
the `locally_echoed` flag should be set to false, as the message has
been confirmed by the server.
This behavior is already correctly handled within the
`echo.reify_message_id()` function, which is triggered through the
`compose.send_message_success()` flow.
However, the on_success function incorrectly sets the `locally_echoed`
flag to true, which is unnecessary and likely a mistake. This led to
the bug where message controls would disappear from the resent messages
on slow networks.
This commit removes the erroneous line to ensure proper flag handling
during message resend.
Previously, the message controls for failed messages was present for
all messages, regardless of their status, and was being rendered
unconditionally; only being hidden for successfully sent messages.
This commit adds dynamic rendering for the failed message controls,
only rendering them via the handlebars template when a message is
confirmed to be failed.
Fixes#31132.
This commit introduced 'creator' and 'date_created'
fields in user groups, allowing users to view who
created the groups and when.
Both fields can be null for groups without creator data.
To be able to convert this module to typescript, we can't create
these objects iteratively, we have to collect the property values
and create it all at once. Partially formed objects aren't very
easy to type.
In cases where the seat count for automated license management is
stale when the upgrade process is initiated and the user has chosen
automated license management, we should get the current billable
license count when doing the initial payment/charge.
Also, makes the post-payment check for inconsistencies more robust
in that we check for both under and over billing cases. In the case
where the customer may have been overbilled, an email is sent to
the billing support team so that manual investigation can happen.
5308fbdeac split out `zulip::postgresql_client`, and 80ef38757a
made it no longer depend on `zulip::postgresql_common`, but directly
on `zulipconf('postgresql', 'version', undef)`. However, the
installer depended on recognizing `zulip::postgresql_common` in the
list of pulled-in classes to know that we needed to keep the
`postgresql.version` setting in `/etc/zulip.conf`.
Update the installer to also recognize `zulip::postgresql_client` as a
class which tells us to keep `postgresql.version` in our settings.
