Refactors compose_closed_ui.update_buttons to cover all three
cases for these button states: direct, stream and non-specfic.
Moves the logic in update_buttons_for_non_specific_views,
update_buttons_for_private, and update_buttons_for_stream_views
to the update_buttons function.
The default case, which is used in views without a filter (i.e.,
recent conversations and inbox), is the non-specific case.
When processing a server event or an empty message fetch,
we were incorrectly updating the closed new conversation
button attribute, "data-conversation-type" to be "direct"
without checking to see if the current narrow filter was
actually a direct message view.
Adds a helper function that checks the current filter for
contains_only_private_messages and then calls
compose_closed_ui.update_buttons_for_private when true.
That's the same check that's used in
message_view.handle_post_view_change when
compose_closed_ui.update_buttons_for_private is called,
so we're consistently using the same check when updating
the closed compose box buttons for this state.
There is no need for 'select_related("usergroup_ptr")' in queries
for NamedUserGroup table because Django always does a join against
base UserGroup table.
For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Anonymous groups were being created for stream permission
settings when calling the subscriptions endpoint without
any streams data or when calling it only for subscribing
users to streams and not for creating any new streams.
This commit makes sure that no such unused anonymous groups
are created.
This commit renames `stream_creator_or_nobody` value for
`default_group_name` field in `server_supported_permission_settings`
object to `channel_creator`.
This commit updates the description for `default_group_name`
field in `server_supported_permission_settings` object to
clearly mention that `stream_creator_or_nobody` is one of
the possible values and explain its meaning.
On visiting 'https://chat.zulip.org/?show_try_zulip_modal',
a 'try zulip' modal is displayed to spectators.
Previously, the modal flashed briefly and disappeared.
Reason:
Earlier, in 'ui_init.js' we called 'show_try_zulip_modal'
followed by a network call - which on success called
'initialize_everything'.
'hashchange.initialize' (in 'initialize_everything') closes
any active modal.
So, the race between 'show_try_zulip_modal' & 'hashchange.initialize'
was resulting in this flash.
Fix:
We call 'show_try_zulip_modal' only after 'initialize_everything'
completes - there's no point to try to display modal when the
loading screen is still visible to users.
When focus for recent view / inbox is in focus, hotkeys were
not working since #36035 didn't account for inputs inside the
view.
Fixed by removing recent view and inbox filter elements from
`.input-element` selector.
Tested that hotkeys now work for recent view, inbox and
channels topics list as expected.
We are not processing this input at the POST endpoint, this
commit just disables the selection from changing.
It is not easy to process changing "import from" at this stage,
but we can possible allow that in a future refactor.
In #35965 we added `push_device_registered_user_ids` to message &
update_message event.
Zulip servers with such events in their event queues when upgraded
to the new version set push_device_registered_user_ids to empty list,
which is incorrect - it leads to no push notification sent.
This commit adds compatibility code to handle such events. The newly
introduced `push_device_registered` check is used only for events
with `push_device_registered_user_id` present in them.
This fixes behaviour where a Docker image with a memory limit would
immediately OOM, as it would not detect the container's memory limit,
only the host's.
Fixes: #29794
The help center documentation now uses astro/starlight, so the
contributor documentation is updated here for the general changes
to that documentation, such as where to find files, and features
and components used in that documentation.
Moves features that are still used for integrations and API docs,
to those guides, e.g., tabbed sections and our macros system, so
that we still have documentation for those systems/features.
Co-authored-by: Shubham Padia <shubham@zulip.com>
Fixes#35899.
We don't make any visual changes to how the svgs/icons look, we just
move them to use the zulip-icon system.
We also replace use of the raw images of each in the help center and add
appropriate color for both in the help center.
The removed lines appear to be fully contrived, as there is no
apparent case where the server would deliver a block of HTML
with `.message_inline_image` without also delivering an inner
<img> or <video> element.
It appears the original outer block was introduced as part of
3df0cacd9e for ensuring coverage
of the post-processing of the `title` attribute to `aria-label`,
which change has since become covered by numerous other
non-contrived examples.
The replaced (and contrived) `<a role="button">` part introduced
by 911b3b5365 is meant to test the
absence of an `href` attribute, which is the minimal new line
introduced here to maintain test coverage while also testing
a genuinely possible pattern a user could send, namely
`[missing href]()`.
See https://chat.zulip.org/#narrow/channel/43-automated-testing/topic/unusual.20.60.2Emessage_inline_image.60.20HTML/with/2261114 for further discussion.
Previously, we enqueued events to "missedmessage_mobile_notifications"
even for users who had no registered push devices.
'handle_push_notification' later used to perform the check & skip
if there were no registered devices.
This commit avoids putting such events into the
"missedmessage_mobile_notifications" queue at all. By doing so,
we reduce unnecessary churn.
We removed this specific feature a few years ago. While the general
docs there are stale in other ways, we can at least remove this
confusing documentation.
Fixes#18326.
GitLab has both integrations and webhooks, and our documentation
should direct users to the webhooks set up for integrating with
Zulip.
Adds a link to GitLab's create a webhook documentation as well.
