When moving content between the include files and the docs files while
copy pasting them, there was a need to change the imports everytime
this was done. This was inconvenient to do.
We considered path aliases to solve this problem but not all editors
support path resolution via those aliases and thus we change the
directory structure instead.
We change imports for components, include files and images in this
commit.
See
https://chat.zulip.org/#narrow/channel/19-documentation/topic/confused.20about.20include.20file
for more info.
Astro was importing these images and doing it's own processing anyways,
there was not a reason for these images to stay in the static folder.
For channels-and-topics.png, we keep the help center directory as the
source directory for two symlinks since that is where the image is
likely to stay the longest.
The image is being duplicated across two places. We make the help
directory the source since it is more likely that an images of channels
and topics will stay in help (given that it has more information)
compared to the emails directory.
Since we have a generic title for the unknown user case for the
"sender" operator, we can now use that when we set the document
title for the narrow view.
Previously, the message header for the "Messages sent by" view for
an invalid or unknown user was the value of the "sender" operand,
which was not a valid/known user email.
Now we show a standard title in the message header for this case:
"Messages sent by unknown user".
If the operand value for the "sender" operand is a known/valid
user, then we can return the value of filter.get_title here,
which correctly handles the guest user case.
Because filter.get_title already returns the translated "Reactions"
string, we can also remove the duplicate logic in compute_narrow_title
for that special view.
As the only caller of pm_emails_string is now pm_ids_string, we
can move getting and checking for the operand value of the "dm"
operator's to be in one function.
Removing pm_emails_string is helpful because it was less obvious
that it could return a value that was not a valid direct message
recipient, i.e., in the case that the user changed the URL manually
or made an error when copy/pasting the URL into the browser.
Use narrow_state.narrowed_by_pm_reply when getting suggestions for
an empty search query to check if the current filter corresponds to
a particular direct message conversation.
Use narrow_state.narrowed_by_topic when getting suggestions for
an empty search query to check if the current filter corresponds to
a specific channel/topic conversation.
This is functionally equivalent to what we have been doing since
these suggestions are only added when the search query is empty.
For narrows that have a term with a near operator or additional
filter terms (is:starred, has:link, etc.), the search query would
not be empty when constructing the attacher for the search box
suggestions.
So that it is clearer that this function is only used when the
search query is empty, we rename suggestions_for_current_filter to
suggestions_for_empty_search_query.
This is a follow-up to #35476 where we made a change in
`compose.clear_compose_box` to clear this banner.
In this commit, we instead club the clearing logic together
with `compose_banner.clear_uploads`.
"Upload profile picture" and similar text shown when hovering
over the image shows a blue outline while clicking on it
and same blue outline is shown when clicking on the delete
button ("x") as well. This commit updates the CSS to remove
that outline.
Emails to missed-message email addressees which are marked
"auto-replied" are clearly auto-replies, and will not contribute
usefully to the conversation. We also ignore "auto-generated" emails
to missed-message addresses, as they must actually be auto-replies
which are misclassifying themselves, as missed-message addresses are
not meant to be targets for any auto-generated emails.
We accept auto-generated and auto-replied emails to stream incoming
email addresses, as auto-generated emails to those are clearly useful,
and auto-replied emails are unexpected enough to allow (given that
Zulip does not produce outgoing emails From: stream email addresses).
If all channels in a folder are muted, then this margin is present
in "Standard view", without there being any folder present.
Fixed by only applying margin if the folder has any header or rows
that are not hidden by filters.
This is an alternative fix to #35962 which was reverted in #36123.
The upstream PostgreSQL default is 4, which is more appropriate for
spinning disks. In general, production deploys almost always use
SSDs; adjust the Zulip default value to a better value for those.
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.