Earlier, for fixed-price plans we were showing the generic
next payment info on billing page which stated that plan
will automatically renew on end_date. It is no longer correct
for fixed-price plans.
This commit fixes the next payment info for fixed-price plans.
When the next_billing_cycle is the end_date, we inform the customer
that their plan will end on end_date and zulip sales will contact
them a couple of month ago before the end_date for renewal.
Earlier, the 'renewal_amount' context variable passed to the billing
template was always a non-empty string which is a truthy value.
The expected behavior is that 'renewal_amount' should be falsy value
if the renewal_cents is 0. This commit fixes the incorrect behavior
and returns None in this case.
This leaves `args.filter_terms` as the raw values the user specified,
before they may have been transformed to the shape that we use for
substring matching.
Sets the max-width for table data cells in the activity and
installation charts.
If the content exceeds the limit, then the overflow is set to
hidden and the text-overflow is set to ellipsis, so there is
a visual indication that the text is not completely visible.
The presence of `len(messages)` outside the transaction caused the
full resultset to be fetched outside of the transaction. This should
ideally be inside the transaction, and also only need be the count.
However, also note that the process of counting matching rows, and
then executing a second query which embeds the same query, is
susceptible to phantom reads, where a query with the same conditions
returns different resultsets, under PostgreSQL's default transaction
isolation of "read committed." While this is possible to resolve by
pulling the returned IDs into a Python list, it would not address the
issue that concurrent updates which change the resultset would make
the overall algorithm still incorrect.
Add a comment clarifying the conditions under which the algorithm is
correct. A more correct algorithm would walk the UserMessage rows
which are unread and in the stream, but this requires a
whole-UserMessage index which would be quite large for such an
infrequent use case.
This makes no immediate reloads the default for runtornado, matching
the production configuration, and changes the development incantation
to be the one to specify the departure from the norm, with
--immediate-reloads.
LoggingCountStats with a daily duration and that are directly stored
on the RealmCount table (not via aggregation in process_count_stat),
can be in a state, after the hourly cron job to update analytics
counts, where the logged value will be live-updated later, because
the end time for the stat is still in the future.
As these logging counts are designed to be used on the self-hosted
installation for either debugging or rate limiting, sending these
partial/incomplete counts to the bouncer has low value.
These are fine instructions, but are specific to the server and
web app, while the surrounding section is otherwise valid for the
project as a whole. Mark them as such, and add a sibling item
for the Flutter app. (Consisting of good advice for becoming
familiar with really any software project, plus a link to the
app's README for specific setup instructions.)
Due to the channel_map_to_topics URL parameter in the Slack webhook,
it was not migrated to use the check_send_webhook_message.
By using check_send_webhook_message, any topic parameter in the
webhook URL will be prioritized over mapping Slack channels to
topics, e.g. when channel_map_to_topics is true. This is because
the default behaviour for incoming webhooks is to send a default
topic as a parameter to check_send_webhook_message in case there
is no topic specified in the URL.
In contrast, we can override the stream passed in the URL when
channel_map_to_topics is false by passing the Slack channel name
to check_send_webhook_message. The default behaviour for incoming
webhooks is to send a direct message if there is no specified
stream in the URL, so a default stream is not generally passed
to check_send_webhook_message.
Fixes#27601.
This change aids in differentiating between a normal user and a bot
account, furthur eliminating any confusion between them (a step forward,
considering how good LLM bots have become in impersonating a real user).
Fixes#25958.
Co-authored-by: 1010nishant <nishantjangid6377@gmail.com>
This commit adds a realm-level setting named
'zulip_update_announcements_stream' that configures the
stream to which zulip updates should be posted.
Fixes part of #28604.
It doesn't make sense for us to track a separate current filter when
it should just the be filter of current message list if there is one.
This will reduce possible confusion in the codebase where filter
returned by narrow_state is different from message_lists.current.
evykassirer
Prakhar Pratyush
David Rosa
Tim Abbott
Aman Agrawal
Anders Kaseorg
Alex Vandiver
Alya Abbott
Lauryn Menard
Greg Price
Bedo Khaled
afeefuddin
Sayam Samal
Sahil Batra
Mateusz Mandera