Commit bd6471f0e3 (#28691) added this
reference to the old name, even though it had already been renamed in
commit b220d29fed (#17775), presumably
because that had failed to update the OpenAPI description.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Fixes#27369.
When editing a topic name via the topic header bar, it's easy to
accidentally move messages into an existing topic, which is
difficult to undo. This commit adds a confirmation modal for when
this is about to happen.
* `font-size: 100%` is unnecessary, as `font-size: 16px` is set on
the `body` selector.
* `text-size-adjust` is unnecessary, as supporting browsers appear
to use `100%` as a default value anyway.
Expands the main query for remote servers to get the audit log
event datetime for when the server was created/registered.
The remote realm object has a field for when the remote realm
was created on the remote server.
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a second step, split
out the subset of fields that pertain to the entire realm.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a first step, split
out the subset of fields that pertain to the current user.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit disables the stream-select dropdown in the "Move message"
modal if the user is not allowed to move messages between streams, and
adds a tooltip for clarification when the dropdown is disabled.
Fixes#28345.
Having a non-identity `cache_transformer` is no different from running
it on every row of the query_function. Simplify understanding of the
codepath used in caching by merging the pieces of code.
Rather than pass around a list of message objects in-memory, we
instead keep the same constructed QuerySet which includes the later
propagated messages (if any), and use that same query to pick out
affected Attachment objects, rather than limiting to the set of ids.
This is not necessarily a win -- the list of message-ids *may* be very
long, and thus the query may be more concise, easier to send to
PostgreSQL, and faster for PostgreSQL to parse. However, the list of
ids is almost certainly better-indexed.
After processing the move, the QuerySet must be re-defined as a search
of ids (and possibly a very long list of such), since there is no
other way which is guaranteed to correctly single out the moved
messages. At this point, it is mostly equivalent to the list of
Message objects, and certainly takes no less memory.
Rather than use `bulk_update()` to batch-move chunks of messages, use
a single SQL query to move the messages. This is much more efficient
for large topic moves. Since the `edit_history` field is not yet
JSON (see #26496) this requires that PostgreSQL cast the current data
into `jsonb`, append the new data (also cast to `jsonb`), and then
re-cast that as text.
For single-message moves, this _increases_ the SQL query count by one,
since we have to re-query for the updated data from the database after
the bulk update. However, this is overall still a performance
improvement, which improves to 2x or 3x for larger topic moves. Below
is a table of duration in seconds to run `do_update_message` to move a
topic to a new stream, based on messages in the topic, for before and
after this change:
| Topic size | Before | After |
| ---------- | -------- | ------- |
| 1 | 0.1036 | 0.0868 |
| 2 | 0.1108 | 0.0925 |
| 5 | 0.1139 | 0.0959 |
| 10 | 0.1218 | 0.0972 |
| 20 | 0.1310 | 0.1098 |
| 50 | 0.1759 | 0.1366 |
| 100 | 0.2307 | 0.1662 |
| 200 | 0.3880 | 0.2229 |
| 500 | 0.7676 | 0.4052 |
| 1000 | 1.3990 | 0.6848 |
| 2000 | 2.9706 | 1.3370 |
| 5000 | 7.5218 | 3.2882 |
| 10000 | 14.0272 | 5.4434 |
This applies access restrictions in SQL, so that individual messages
do not need to be walked one-by-one. It only functions for stream
messages.
Use of this method significantly speeds up checks if we moved "all
visible messages" in a topic, since we no longer need to walk every
remaining message in the old topic to determine that at least one was
visible to the user. Similarly, it significantly speeds up merging
into existing topics, since it no longer must walk every message in
the new topic to determine if the user could see at least one.
Finally, it unlocks the ability to bulk-update only messages the user
has access to, in a single query (see subsequent commit).
We previously had code to disable the "Add" button initially but
then we re-enabled it again if user had permission to add members.
We do not need that code to enable/disable the button based on
permission since the button is disabled initially and it is
only enabled when user updates the input which is not allowed
if users is not allowed to add members.
Previously, when there is no valid pill in the members list and
user clicks on "Add" button, then "No user to add" error is shown
but the error message is visible until successful user is added
and the same goes for success messages too.
This commit updates the code to remove both error and success
messages when user types in the input.
Previously, when there is no valid pill in the members list and user
clicks on "Add" button, then "No user to subscribe" error is shown
but the error message is visible until successful user is added and
the same goes for success messages too.
This commit updates the code to remove both error and success messages
when user types in the input.
Fixes#27438.
In the Personal settings stream management panel,
when notification settings are changed, Saving/Saved
indicator are shown on personal settings heading instead
of notification settings heading.
Fix this issue by showing indicator on
notification settings heading.
Fixes: zulip#28728.
This commit addresses code duplication issue in
'stream_is_muted_changed()' which was redundantly
present in 'stream_setting_changed()'.
The changes ensure that the functionality is now centralized
and can be easily updated or extended in the future.
Adds a link on the upgrade and billing pages that opens a stripe
billing portal for the customer to update their name and address
that will appear on invoices and receipts.
On the billing page, updating the credit card information will
no longer update the customer billing address, since they can
now do this directly through the billing portal. To be consistent
with the credit card form on the upgrade page, we still require
inputting a billing address for the card.
Note that, once an invoice is paid/complete, then changes to the
customer's name and address will not be applied to those invoices.
Set the name on the stripe customer object to the name on the
credit card when one is initially attached to a customer.
Prep commit to adding a stripe billing portal so that billing
admins will be able to update both the name and address that
appears on their stripe generated invoices and receipts.
Anders Kaseorg
evykassirer
Karl Stolley
Lauryn Menard
Varun-Kolanu
Vector73
Alex Vandiver
Tim Abbott
Sahil Batra
cherish2003
somudas
qx24680
vighneshbhat9945