This was causing a bug where the participants weren't necessarily
all getting rendered, specifically when there were many subscribers
to a channel, because we render users in batches as buddy list
scrolls, and those users would only show up after some scrolling.
This fix makes sure we always load the participants first.
Previously, for big orgs, we hid all offline users in the buddy list to cut down
its size. But this can be weird for small channels where you might want to see
who's in the channel. This commit makes a tweak to show offline users in big
orgs for channels of size <= 50.
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.
Instead of current_user.user_id we use page_params.is_spectator
field to check the spectator cases as it makes it more clear
to the reader about what is the condition checking.
Note: This involves adding presence info of unknown users to the
presence data.
With some small tweaks, we can just add the info to the presence data
structures, just making sure the buddy list correctly skips those
entries and that we redraw the user in the case where the user creation
event arrives after the presence polling loop.
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>
This commit adds code to add "(guest)" to user names of guest
users in the following places -
- right sidebar
- user pills, including the pills in search suggestion typehaead
- typeaheads for user
- sender names in message feed
- user profile popover and modals.
- user name in not subscribed warning banner.
Note that the indicator is shown only if enable_guest_user_indicator
setting is set to true.
As a result of this change, we now translate "deactivated" text
shown in user pills for deactivated users.
Fixes part of #26700.
We should search for what the user asked us to search for.
CZO conversation:
https://chat.zulip.org/#narrow/stream/101-design/topic/search.20buddy.20list.20for.20self/near/1630454
This commit also stops the user from being at the top of
the search list, so that the search list is fully
alphabetical (though still sorted by online status).
We switch to not having the user at the top of the list
only when there's search text in the search bar, otherwise
there'd be a visual jump that would happen just by opening
the search bar. There's almost always visual change when
entering text into the search input field, so that seems
like the time to change the sorting.
We should make `get_by_user_id` type-safe in the sense that it's caller
should not expect undefined values and hence it's caller should not
need to validate the user ids.
To do this I extracted a method `maybe_get_user_by_id` which is
type-unsafe version of this function which will allow undefined values
and will behave exactly the same as the previous version. So the callers
which expects the undefined values from this function should use this
new function `maybe_get_user_by_id`.
Probably about half of these callers are implicitly iterating through
all users in the people.js data set and thus by construction should
never fail, but it's simpler to just convert all existing callers than
do that audit.
Adds support in the web app for `dm` operator. This will deprecate
the `pm-with` operator, but existing links/URLs are still supported
for backwards-compatilibity.
This commit updates the web app default behaviors to default to
the new narrow/URLs `dm/...` and `/#narrow/dm/...` when navigating
and searching in the app.
There is some general clean up of references to private messages
or PMs to be either direct messages or DMs in these changes.
The general API changelog and documentation updates will be done
in a final commit in the series of commits that adds support for
the various new direct message narrows.
This lets us simplify the long-ish ‘../../static/js’ paths, and will
remove the need for the ‘zrequire’ wrapper.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Anders Kaseorg
evykassirer
adnan-td
Mateusz Mandera
Sahil Batra
Lalit Kumar Singh
Lauryn Menard
Alex Vandiver
Ujjawal Modi