We will redraw the list on every deactivation or reactivation.
While that might seem expensive to redraw on each user, the other
option we have is to have some logic run each time the tab is selected
and redraw if the user list has changed.
Since deactivation and reactivation is not something that an admin
would do multiple times a day, redrawing on each user should be fine
for now.
We will continue displaying the reactivated/deactivated users in a
greyed out column after the live-update, since it is weird for a user
to disappear suddenly from the list.
Use user events to update profile tab for a
synchronized experience across all users.
Fixes#26692.
Co-authored-by: Kunal Sharma <v.shm.kunal@gmail.com>.
Co-authored-by: Angelica <angelica.ferlin@gmail.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.
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.
Add a personal menu dropdown that opens on clicking user avatar icon
in navbar added in previous commit.
The args passed to render_personal_menu() in onShow() are returned by
get_personal_menu_content_context() in popover_menus_data.js so that
they can be unit tested.
Additionally, added CSS to get a custom arrow for dropdown menu.
Added a `?` hotkey in keyboard shortcuts option in personal_menu
dropdown in a style similar to our tooltip's hotkey by adding
? in a span with class .tooltip-hotkey-hint and adding some CSS.
Fixes part of #22802.
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.
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>
Shubham Padia
sanchi-t
Vector73
evykassirer
Anders Kaseorg
Evy Kassirer
Sahil Batra
Hardik Dharmani
Lalit
Alex Vandiver