This migration references the "confirmation" app for the first time,
which means we must have migrated at least part of it by this point.
Set the migration to depend on the latest "confirmation" migration at
the time of this migration.
This keeps colors uniform between edit and preview modes, and also
ensures no bleedthrough of the editor when in preview mode.
ID selectors have been used for those colors to both keep the text
color declaration in the same place, and to avoid a dark-theme
specificity problem where the generic textarea took precedence over
the colors specified on the compose box's own textarea.
Migrate the following endpoints from @has_request_variables
to @typed_endpoint:
- get_user_group()
- delete_user_group()
- update_user_group_backend()
- update_subgroups_of_user_group()
- get_is_user_group_member()
- get_user_group_members()
- get_subgroups_of_user_group()
With tweaks from tabbott to avoid calling thunks unnecessarily.
The default compression level is 1; increasing this to 3 takes a small
amount more CPU time (single-digit ms on multi-MB transfers), but
results in a small but noticeable (4-7%) percentage better
compression in JSON content.
Assuming a 25 megabit connection (the current average data rate for
cell phones in the U.S.), a 2MB file which is shrunk an additional 4%
saves approximately 25 milliseconds of transfer time; thus the
additional few milliseconds of CPU-time is well worth the cost. For
faster connections (e.g. 100 megabit), the tradeoff is more or less a
wash.
Earlier, we were using 'send_event' in 'do_schedule_messages' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_update_user_status' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were immediately enqueueing event in
'do_remove_alert_words' which can lead to a situation, if any
db operation is added after enqueueing event in future, where the
action function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_add_alert_words' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Function `message_helper.process_new_message` takes a
`RawMessage` and throws out `Message`. But here we are
passing it an already processed msg of type `Message`.
This is completely type unsafe. Since our purpose here is to
replace our old message object with a latest copy from
`message_store`.
We can do this directly without calling `process_new_message`.
With the refactoring of the rendered-Markdown area to use only
margin bottom, including in message-edit previewsk, these expensive,
general selectors are unnecessary.
Headings and horizontal rules, which do have margin-top, are zeroed
out elsewhere in the rendered-markdown file.
Because the compose-box resize logic is tied to the size of the
textarea, it's possible when resizing in preview mode that the
state of the compose box is not properly tracked. That's because
the height logic in `autosize_message_content` assumes a visible
textarea.
However, because both the textarea and the message preview area
occupy the same named grid area (`message-content`), and because
the preview area comes after the textarea in the DOM, when visible,
the preview area will automatically cover (and be sized to) the
textarea. And because the textarea remains observable in the DOM,
the compose box will obey the same expansion logic in preview mode
as it does in edit mode.
As of 1f68726cb8, the upgrade-postgresql tool uses Python to connect
to the database used by Django, and thus requires a working venv.
There is no reason we cannot reinstall the venv with the old version
of PostgreSQL; swap the steps.
GitHub sends two almost identical payloads when a pull
request is reviewed, which results in two duplicative
notification messages.
The payloads have different "action" value, with one
having the "submitted" action, whereas the other is
"edited" and has an empty "changes" dict.
We now ignore the payload with the "edited" action type
and an empty "changes" dict.
Fixes#26145.
Co-authored-by: Pieter CK <pieterceka123@gmail.com>
Because Django does not support returning the inserted row-ids with a
`bulk_create(..., ignore_conflicts=True)`, we previously counted the
total rows before and after insertion. This is rather inefficient,
and can lead to database contention when many servers are reporting
statistics at once.
Switch to reaching into the private `_insert` method, which does
support what we need. While relying a private method is poor form, it
is mildly preferable to attempting to re-implement all of the
complexities of it.
Alex Vandiver
Karl Stolley
bedo
Lauryn Menard
roanster007
Kenneth Rodrigues
Prakhar Pratyush
afeefuddin
Tim Abbott
Anders Kaseorg
Mateusz Mandera
Varun Singh
Alya Abbott
lumpleme
adnan-td