There is no need to filter down the streams returned
by get_streams_for_user to the streams for which
stream_data.can_subscribe_others is true, as
get_streams_for_user(user_id).can_subscribe only includes
the streams for which stream_data.can_subscribe_others
is true.
This commit removes the unnecessary filter call.
This commit renames "default" views to "home" views in the setting
labels, keyboard shortcuts list, help documentation and its urls.
This commit does not do changes in variable and class names, setting
field in database, API docs and changelog.
Fixes part of #27251.
Thisi and the following commit follow the approach used in
3e2ad84bbe.
First migration requires a server restart - after that any new realms
will be created with the columns set.
The following migrations are in the next commit:
Second migration does a backfill for older realms and can run in the
background while the server is operating normally.
Third migration enforces null=False now that all realms have the columns
set.
This is documented on the page about organization language, but makes sense
to include here as well.
Also reordered preferences to match the order in the menu.
Rerendering of "all messages" is slow, and by definition, not visible
to the user, so make sure the browser gets an opportunity to rerender
the content that is visible before starting that expensive
computation.
Add an optional `automatic_new_visibility_policy` enum field
in the success response to indicate the new visibility policy
value due to the `automatically_follow_topics_policy` and
`automatically_unmute_topics_in_muted_streams_policy` user settings
during the send message action.
Only present if there is a change in the visibility policy.
Fixes#27208. Fixes#27207.
We only process messages from all_messages_data and special data
fetched for recent view only.
This avoids us having a conversation present in recent view which is
not contiguous due to loading a random old conversation.
Also, to ensure displayed conversations are contiguous while we are
loading data, we don't show message list data until we have found the
newest message in the list.
This reverts the typeahead library part of commit
0cdb54cf65.
The extra refocusing was breaking the `>` typeahead acceptance logic.
Further, generally typeahead acceptance won't introduce block syntax
or newlines, so I'm not sure whether the original motivation for doing
this in other code paths applies to typeahead.
We were using id before to increase their specificity, but
since it is possible for multiple empty_list_widget_for_list/table
to be in DOM at the same time, we should use a class here. Used
`!important` here so that we can force our padding where these
classes are used.
When focused on filters, `r` keypress to open compose had
`msg_type` set to undefined which shouldn't be the case ever as
we always expect msg_type to be defined when compose is open.
If the last returned value of `insert_stream` was false, `has_topics_post_filter`
was false and hence this empty text was visible.
We only need one of the inserted streams to visible to hide the empty text.
Reproducer:
* Mark all messages as read.
* mark one message in denmark as unread.
* mute #support (any stream that would come later to denmak alphabetically)
* sent a message support from a different user while inbox is open.
The CSS variables for heights in subscriptions overlay uses
"modal" word but we actually use overlays for subscriptions
UI, so this commit renames those variables to better names.
We use "modal-body" class in informational overlays and
"About Zulip" overlay. For informational overlays, the
class is used on the element acting as scroll container
so we just rename the class to "overlay-scroll-container".
For "About Zulip" overlay, we do not support scrolling
so "overlay-body" seems a better class name.
We only use "modal-footer" class in stream and user group
creation forms which is actually not a modal, so this commit
renames the class to a better name "settings-sticky-footer".
Python evaluates function parameter defaults at definition time, not
call time. This function wouldn’t work with other realms anyway.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
As a preliminary step for including graphs of StreamCount data in our
analytics pages, add API support for fetching the chart data.
Care is taken to limit access to streams that the current user has
access to, which isn't necessary in similar views where the current
user is a server administrator by assumption.
Fixes part of #19653.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
We now show tooltip on "Unsubscribe" button in user profile modal
if the stream is private and the user is last user in the stream
mentioning that user should use stream settings to unsubscribe.
This commit adds a confirmation modal that appears when an administrator
attempts to unsubscribe the only user currently subscribed to a private
stream. The modal includes a warning message explaining that the private
stream will be automatically archived after unsubscription.
Fixes#24025.
This commit adds "?" to the heading of modal shown when unsubscribing
user from private stream and adds a link to help documentation for
archiving streams. This commit also refactors the code such that we
can use the same template to show modal when unsubscribing others
from private streams.
Fixes#27209
Since post_scroll__pre_render_callback is called to set
the correct focus, we don't need to set focus again here.
This was happening because `set_table_focus` relies on rows
being already rendered in the DOM which is not the case with
page down since rows are still being rendered by list widget
as we scroll down.
This code was the source of the error:
```
if (new_scrollTop >= table_height) {
row_focus = topics_widget.get_current_list().length - 1;
}
```
row_focus set here is not rendered yet, hence making set focus
on search box.
But, since we set focus on table if user is scrolling, this
sets focus back on the table.
Fixes#27207
The recent view's data sources are mainly all_messages_data,
but if you click into a stream via the left sidebar that has
no recent conversation history, one can reliably reproduce that
some of those conversations will end up being displayed in the
recent view, despite not being temporally contiguous with what
it has data for.
To avoid it, we only process messages fetched for all message data.