Previously animated images were automatically played in the
message feed of the web app.
Now that we have still thumbnails available for them, we can add a new
personal setting, "web_animate_image_previews", which controls how the
animated images would be played in the web app message feed -- always
played, on hover, or only in the image viewer.
Fixes#31016.
In a2ef1d7e93, we made changes so
that when you send a message, your view jumps to the conversation
where you sent it.
For some users it was an improvement, few reported that it
disrupts their workflows.
This prep commit adds a setting which will be used to allow users
to decide whether to automatically go to conversation where they
sent a message.
We will now just run the actual template if not mocked, such that code
that ends up rendering a template incidentally does not need to mock
templates.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit removes create_public_stream_policy setting
since public channel creation permissions are now handled
by group-based setting.
We still pass "realm_create_public_stream_policy" in
"/register" response though for older clients with its
value being set depending on the value of group based
setting. If we cannot set its value to an appropriate
enum corresponding to the group setting, then we set
it to "Members only" considering that server will not
allow the users without permissions to create public
channels but the client can make sure that UI is
available to the users who have permission.
We want to make it easier to find stream details such as creator,
creation date and stream id. The commit replaces the "Email address"
section in General tab of stream overlay with a new section called
"Stream details", "Email address" is now a field in this section.
If the stream does not have a creator, we only show the stream creation
date in creation details.
Fixes: #25648.
This commit adds an option to the advanced section of
Preferences settings, that would allow users to choose
whether to receive typing notifications from other
users.
Fixes#29642
To achive this the `stream_header_colorblock` div was removed from
`dropdown_widget_with_stream_colorblock.hbs` template. this change made
the file name irelevenet so it was necessary to rename the file to
`dropdown_widget_wrapper.hbs`. After removing the html strcuture for
colorblock from templates the css for colorblock was also removed.
followed by the javascript which was used to add colorblock to the
stream picker. After removing javascript tests were updated.
Fixes: #28796.
This commit adds a realm-level setting named
'zulip_update_announcements_stream' that configures the
stream to which zulip updates should be posted.
Fixes part of #28604.
This commit renames the realm-level setting
'signup_notifications_stream' to 'signup_announcements_stream'.
The new name reflects better what the setting does.
This commit renames the realm-level setting 'notifications_stream'
to 'new_stream_announcements_stream'.
The new name reflects better what the setting does.
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a second step, split
out the subset of fields that pertain to the entire realm.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a first step, split
out the subset of fields that pertain to the current user.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Some files already were using `noop` in place of `() => {}`.
It's both clearer what it means and is easier to type.
This updates all test files to fully use `noop`, and
adds a shared import from the test lib file.
Earlier, the event sent when an onboarding step (hotspot till now)
is marked as read generated an event with type='hotspots' and
'hotspots' named array in it.
This commit renames the type to 'onboarding_steps' and the array
to 'onboarding_steps' to reflect the fact that it'll also contain
data for elements other than hotspots.
This commit introduces non-intro hotspots.
They are a bit different than intro hotspots in the
following ways:
* All the non-intro hotspots are sent at once instead of
sending them one by one like intro hotspots.
* They only activate when a specific event occurs,
unlike intro hotspot where they activate after the
previous hotspot is read.
This commit removes "email_address" field from Subscription objects
and we would instead a new endpoint in next commit to get email
address for stream with proper access check.
This change also fixes the bug where we would include email address
for the unsubscribed private stream as well when user did not have
permission to send message to the stream, and having email allowed
the unsubscribed user to send message to the stream.
Note that the unsubscribed user can still send message to the stream
if the user had noted down the email before being unsubscribed
and the stream token is not changed after unsubscribing the user.
We now send "realm_user/update" (and "realm_bot/update" for bots)
events with "is_active" field when deactivating and reactivating
users, including bots.
We would want to use "remove" event for a user losing access
to another user for #10970, so it is better to use "update"
event for deactivation as we only update "is_active" field
in the user objects and the clients still have the data for
deactivated users.
Previously, we used to send "add" event for reactivation along
with complete user objects, but clients should have the data
for deactivated users as well, so an "update" event is enough
like we do when deactivating users.
This commit renames default_view and escape_navigates_to_default_view
settings to web_home_view and web_escape_navigates_to_home_view in
database and API to match with our recent renaming of user facing
strings related to this.
We also rename the variables, functions, comments in code and class
names and IDs for elements related to this.
This commit replaces the value `private` with `direct` in the
`message_type` field for the `typing` events sent when a user
starts or stops typing a message.
Updates the testing for scheduled message event schemas to be fully
checked by `zerver/tests/test_events.py` and `tools/check-schema`.
Adds the missing 'failed' field to the scheduled message events
in `web/tests/lib/events.js` as well.
This test did extensive mocking and didn't feel like it either fully
tested the module or did a good job of testing the logic; and will
break with the migration to tippy. I think it's better to remove the
test and plan to write a new one testing just
get_user_card_popover_data, the actual interesting part for node tests
of this module.
Added a show_unread_counts personal user setting to the
Settings > Display settings > Advanced section which
lets user choose whether he/she wants to see unread messages
count on the left sidebar for streams.
This setting have three options,
"All Streams" - This will show unread messages count for all
streams.
"Unmuted Stream" - This will be default option and it will
only show unread messages count for unmuted streams.
"No Stream" - This option will not show unread messages count
on any stream.
Fixes#24149
This commit adds code to pass stream traffic data using
the "stream_weekly_traffic" field in stream objects.
We already include the traffic data in Subscription objects,
but the traffic data does not depend on the user to stream
relationship and is stream-only information, so it's better
to include it in Stream objects. We may remove the traffic
data and other stream information fields for Subscription
objects in future.
This will help clients to correctly display the stream
traffic data in case where client receives a stream
creation event and no subscription event, for an already
existing stream which the user did not have access to before.
roanster007
evykassirer
Vector73
Aman Agrawal
Prakhar Pratyush
sanchi-t
Sahil Batra
Anders Kaseorg
tnmkr
Karl Stolley
Mahhheshh
Mateusz Mandera
Prakhar Pratyush
Alex Vandiver
Evy Kassirer
Riken Shah
Lalit Kumar Singh
Dinesh
Lauryn Menard
Tim Abbott
Ujjawal Modi