This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
This is part of a bigger refactor to calculate message list group
attributes and creating the group all at once instead of piecewise.
This is necessary to convert this module to typescript, since a
partially formed group is hard to type.
This is part of a bigger refactor to calculate message container
attributes just from the message, so that we can create the message
container all at once instead of piecewise, to be able to convert
to typescript.
Previously, in presence of `dm` operators, the `with` operator
behaviour in the web client was not consistent with that of
the API. For instance, when `with` points to a stream message,
in presence of a `dm` term, then rather than narrowing to the
corresponding channel of `with` operand, the `with` term simply
used to be ignored, and narrowed to the corresponding `dm`
narrow.
Also, in cases when the `with` used to point to a direct message,
in presence of a `channel` term, then after correcting to the
right narrow, the `with` term used to be removed. The `with`
term would still be needed after correcting the narrow to
maintain consistency between channel and dm conversations.
This commit removes these inconsistencies of `with` in case
of `dm` operators, and makes it consistent to those mentioned
in the api documentation.
Shows a stream info popover whenever a channel pill is clicked (such
as in the pill widgets for adding subscribers to a channel or
invitations). The stream info popover contains channel icon and name,
channel description and a link to channel settings.
Fixes#30567.
If we receive a message that we can add to the data cache without
talking to the server, we do that, otherwise we remove it from the
cache to avoid us having wrong filter status cached.
We start caching MessageListData objects for the narrows which
user has visited. We restore the cached objects if the filters
match. Also, the cached objects are updated based on events. One
major piece is update path the is pending implementation is the
message move code path.
This is an easy way to track if a MessageListData is rendered.
Storing MessageList object would make us liable to cleanup the
MessageList object when the data is no longer in use.
Note that this is more like "likely / past rendered message list id",
we will have to check currently rendered message list data to verify
if the data object is really rendered.
As part of our todo in the code, we want to use the unique user IDs
instead of emails when processing the results of subscribing users to a
channel. These changes apply those changes and streamlines the use of IDs.
This param allows clients to specify how much presence history they want
to fetch. Previously, the server always returned 14 days of history.
With the recent migration of the presence API to the much more efficient
system relying on incremental fetches via the last_update_id param added
in #29999, we can now afford to provide much more history to clients
that request it - as all that historical data will only be fetched once.
There are three endpoints involved:
- `/register` - this is the main useful endpoint for this, used by API
clients to fetch initial data and register an events queue. Clients can
pass the `presence_history_limit_days` param here.
- `/users/me/presence` - this endpoint is currently used by clients to
update their presence status and fetch incremental data, making the new
functionality not particularly useful here. However, we still add the
new `history_limit_days` param here, in case in the future clients
transition to using this also for the initial presence data fetch.
- `/` - used when opening the webapp. Naturally, params aren't passed
here, so the server just assumes a value from
`settings.PRESENCE_HISTORY_LIMIT_DAYS_FOR_WEB_APP` and returns
information about this default value in page_params.
Since `success_message_scheduled_banner` and scheduled message overlay
both use `data-scheduled-message-id`, `get_element_by_id` needs
to be more specific which selector it wants.
Earlier, the content of the "manage_preferences" block that includes
the unsubscribe_link, personal settings link, etc was missing in the
plaintext version of the custom emails.
This commit updates the logic to include the manage_preferences block
content in the plaintext version.
Previously, the emails sent to the remote servers had the
'unsubscribe link' only present in the 'List-Unsubscribe' header.
Not all email clients expose that header.
So, this commit adds the link in the footer too.
This commit makes small refactoring to place all the user-privacy
settings code in 'server_events_dispatch.js' at one place and use
a common function 'settings_account.update_privacy_settings_box' to
update the UI.
This also helps in early return instead of executing a lot
of `if` statements related to user-preferences settings.
The following three privacy settings weren't being live
updated across multiple browser tabs/windows:
* send_stream_typing_notifications
* send_private_typing_notifications
* send_read_receipts
This commit fixes the bug.
This commit performs a minor code restructuring to use the
generic code block for updating all the user_preferences
settings values.
No need to use a separate code block for 'enter_sends' setting.
Fixes test that checks for error when invalid value is given for a property
in realm. Currently, only properties with type int are checked, leaving
properties having optional int type. This commit fixes that.
Now that we store the content-type in the database, use that value
(if we have it, since we did not backfill) when serving content back
to the client. This means the file backend has parity with the S3
backend.
Imported Slack bots currently do not have owners (#23145). Soften the
deactivation codepath to allow them to be successfully deactivated
despite this.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
evykassirer
Mateusz Mandera
roanster007
opmkumar
Varun Singh
Tim Abbott
Aman Agrawal
Ikko Eltociear Ashimine
joseph
Bedo Khaled
Karl Stolley
adnan-td
Prakhar Pratyush
Vector73
Alex Vandiver