This is most important for `send_zulip_update_announcements`, which
can race with the version run as a post-deploy hook. However, all of
these crons can tolerate being slightly delayed, and there's little
benefit to them taking CPU or possibly hitting odd borderline race
conditions when the deploy is in progress.
For safety, we only trust the deploy lockfile if it was created
within the last hour -- deploys should not take more than an hour, and
failing to ever run hourly crons is much worse than perhaps running
them during a real very-long deploy.
Exports from other apps obviously don't come with Welcome Bot messages -
which isn't a great experience as it is, as those are meant to help with
onboarding. We should generate them for all users at import time.
We limit the set of users to active accounts to make the workload more
reasonable in case of large orgs with plenty of deactivated accounts.
The downside is that an imported user joining after being reactivated
will be lacking these messages. We can re-think this approach if needed.
Fixes#34820.
This logic was fundamentally broken:
```
is_realm_imported_from_other_zulip_server = RealmAuditLog.objects.filter(
realm=realm, event_type=AuditLogEventType.REALM_EXPORTED
).exists()
if not is_realm_imported_from_other_zulip_server:
send_zulip_update_announcements_to_realm(
realm, skip_delay=False, realm_imported_from_other_product=True
)
```
Because the `REALM_EXPORTED` was only created after the export completed
- meaning it couldn't be included in the export data at all. Thus
considering exports to be "not from Zulip" incorrectly.
We get around this issue by explicitly including an import_source in the
realm dict in the export data from 3rd party apps. The importer can then
rely on this value to determine if it's dealing with a Zulip-originated
export or not.
This commit adds a `push_devices` dictionary to
`POST /register` response, keyed with push account ID,
where each entry describes the user's push device's
registration status and error code (if registration failed).
This commit adds a `PushDevice` model where each row
corresponds to an account on an install of the app
that has attempted to register with the bouncer to
receive mobile push notifications.
This is the core server table storing registrations
that are potentially registered with the mobile push
notifications bouncer service.
This commit adds a zilencer endpoint to let self-hosted
servers register push devices to whom mobile push notifications
will be sent.
POST "/api/v1/remotes/push/e2ee/register"
Payload: realm_uuid, push_account_id, encrypted_push_registration,
bouncer_public_key
The post request needs to be authenticated with the server’s API key.
Note: For Zulip Cloud, a background fact about the push bouncer is
that it runs on the same server and database as the main application;
it’s not a separate service.
So, as an optimization, we plan to directly call the
`do_register_remote_push_device` function and skip the HTTP request.
The 'user_uuid' parameter of 'get_remote_realm_helper' was only
used for logging when realm lookup fails, but we've never made
use of that detail in practice.
There is no strong reason to keep that.
This commit removes the JavaScript logic that was used to determine
whether an input field was empty or non-empty. The CSS pseudo-classes
and selectors seem robust enough to handle the styling based on the
input state without needing additional JS logic at the moment, and
removing this JS logic simplifies the codebase and prevents potential
conflicts with the CSS styles.
This commit refines the logic for determining when the filter input with
pills is empty. The JS logic is removed from web/src/topic_list.ts,
as this new logic is now handled in the CSS, common across all filter
inputs with pills — resulting in a consistent and predictable behavior
for empty states on all the new filter inputs.
This commit adjusts the left and right padding of the input element in
the filter topics input to account for the left and right borders.
This ensures that the text inside the input is aligned with the text in
other elements of the left sidebar grid.
This follow-up commit fixes the incorrect input color values that were
introduced in the initial commit. This change is most visible in the
'hover' state where the values were incorrectly set to the same values
as that of the normal state, leading to a lack of visual distinction.
This follow-up commit replaces the current left sidebar topic list
filter input implementation with the redesigned input_wrapper
component.
This commit also serves as the base for supporting inputs using the
search_pill_widget, and thus adjusts the previously defined logic at
certain places to ensure that the input pills are handled and
displayed accurately.
Fixes part of #34476.
This prep commit consolidates the input pill styles into
`app_variables.css` and uses the light-dark notation for the color
variables to avoid specificity issues that arose from `dark_theme.css`.
This commit eliminates a bug, introduced in commit
7bc04bb829, where the send button's
tooltip hotkey hint would have incorrect placement when the user had
triggered a tippy instance on the send button while it was disabled.
The reason behind this bug was the conflict between code in the
previously mentioned commit which set the tooltip content to
`display: block` to account for the inline italicized empty topic name
in the error message, and the need for `display: flex` to ensure the
hotkey hint was positioned correctly.
Fixes#35116.
We copied whatever logic we needed from documentation_main.html. We have
not added the policy footer case from that html file into our footer
since that case does not apply to the new help center yet.
We process and pass the support email in the build help center step.
Previously, narrowing to empty topic only channel keeps message list
faded even if the compose recipient to set to that channel. This commit
fixes this bug.
The Flutter mobile apps don't collapse repeated spaces into single
spaces the same way HTML text does, so leading/trailing whitespace in
these automated messages end up rendering weirdly.
The regex previously didn't handle a corner case that appears in the
latest message.
Co-authored-by: Greg Price <greg@zulip.com>
This commit aligns navigation view event type with Python event schema
classes. The schema validation script constructs class names from event
types, so this commit ensures the navigation view event type match the
expected EventNavigationView class names.
