On reactivate or deactivate, we add appropriate class through JQuery.
But that class only remains there until sort, on sort any of these added
classes will be removed. We did not face the problem of un-greying for
active users page, because deactivated_users class was added to the HTML
always if `is_active` was false for the user.
In this commit, we rename `reactivated_user` to `active-user` and this
class will be present for all active users, even on the active users
table. For the deactivated users table, we will have scoped css that
will grey out the row with `active-user` class.
Fixed#29894.
We were using `is_active` to determine whether to show that column or
not. In case of deactivated table, on reactivating a user, `is_active`
will become true for that user, but we still don't want to show that
column and mess up our layout. Same would happen in the active users
table when a user was deactivated and the `is_active` would become
false. It is better to control the column to be shown on a per-table
basis and we introduced `display_last_active_column` to control that.
Co-authored-by: shubham-padia <[email protected]>
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.
Previously, there were three different sections for managing active
users, deactivated users and invitations.
This commit combines users section has into a single tabbed panel.
Fixes: #26949.
Co-authored-by: shashank-23002 <[email protected]>
Since the type of request_method(AjaxRequestHandler) has
been extended in the previous commit.Consequently the 'data'
field of 'request_method' has to be typed such that it
satisfies this change.
Because request_method's type can also be 'typeof patch' which
does not accept undefined 'data' field, I haved 'omit'-ted
'undefined' from 'data's type in function signature to satisfy
TypeScript.
Now ,in support of the changes I have made to two different function
sign(namely setting_ui.do_settings_change,dialog_widget.submit_api_request)
I am stating some points about data field inside these respective
function signs.
1.settings_ui.do_settings_change: For this 'data' was actually never
undefined. Each function call has a 'data' object passed( with one
or more fields).
2.dialog_widget.submit_api_request: For this case many function calls
actually didn't have 'data' field (ie.'data' was undefined).
BUT,for those cases it was defaulted to '{}'(see function sign).
So effectively 'request_method' didn't recieve an undefined 'data' for
this case too. I have removed the defaulting and passed '{}' in the
function calls for those cases, which effectively does the some job,
but satisfies the type.
For both these cases 'data' field isn't undefined and hence an Omit,for me
makes sense.
Fixes#18617.
- The role filter is added to both active and deactivated user
list. The original plan was to introduce a multi select checkbox
dropdown for the roles, but since that component is not ready yet,
we will use the dropdown component for the first iteration.
- To accomodate multiple filters, we have used an approach
similar to the one in recent_view_ui.js where we use dropdown
callback function and on("input") event on text search to set the
filter value in memory. The predicate functions uses these filters.
- We have also changed the default message when there are no
users to show to reflect `filters` instead of `current filter`.
Display manage this user in the three-dot menu on the user card
regardless of is_active.
Similarly, display edit user icon in deactivated users list.
Do not hide edit button when user is deactivated.
Fixes#29486.
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 <[email protected]>
Earlier when a user is deactivated or reactivated from users
table and deactivated_users table the `Role` column was modified.
This commit changes this and now `Role` column is not modified
instead now the corresponding row is greyed out.
Fixes#21653.
This commit removes the `Reactivate` and `Deactivate` title on hovering
to activate and deactivate button in users and deactivated_users table.
This was done as we already show tippy tooltip on hover.
This commit creates a new file user_deactivation_ui.js which
now contains the code for showing deactivation modal for user
and bots.
Since confirm_deactivation and confirm_bot_deactivation functions
are used in multiple places, this change helps us in avoiding
import cycles.
Since the user-edit form is opened inside user profile modal,
user_profile.js is a better place for show_edit_user_info_modal
function and would help us in removing import cycles as well.
When changing name of users, the name was updated corectly
in the "Users", "Deactivated users" and "Bots" list but
it removed the "<a>" element, used to open the user
popover, and instead changed it to plain text.
This commit updates the code to just update the text inside
"<a>" tag so that the popover can still be opened by clicking
on the name.
We don't have a "Manage user" tab in your own profile, so it would
throw an exception to do the default thing here, and the mechanism for
editing your own settings should be the main "your profile" panel,
which is a bit bigger and more user-friendly.
I'm not totally convinced that the extra logic for not having a
"Manage user" tab is worth it; the alternative of figuring out a
non-confusing label would not be terrible here. But this version is
non-broken, and it'll be easy to change later if we change our mind.
This commit disables the "Deactivate User" button inside the
"manage user" tab in the user profile modal. Additionally, a
tooltip is applied to the button by wrapping it inside a div
with the tooltip applied.
This commit migrates the "Manage Bot" modal to the user profile modal,
with the same explanation as in the "Manage User" modal commit.
However, in this commit, we changed the permission of the "Manage User"
tab so that non-admin users can also see the "Manage Bot" tab if they
have created the bot. Additionally, since we can't make changes to
system bots, we check if the bot is a system bot and hide the
"Manage Bot" tab accordingly.
Fixes: #21806
This commit migrates the "Manage User" footer buttons to the user
profile modal. We made this change because we don't want the buttons
to scroll with the content; instead, we want them to be sticky at
the bottom at all times. Therefore, we moved the buttons to the user
profile modal.
This commit migrates the "manage user" modal to the "Full Profile"
modal. Refactored the show_edit_user_info_modal function since
earlier, we used to have a separate "Manage User" modal.
Consequently, we checked if we were coming from the
user_info_popover and then built the dialog widget accordingly.
However, with this new change, we no longer need to build the
dialog widget. Therefore, removed that part and now just pass
the container of the 'user profile modal' to get the content.
Previously, for deactivation, we used to have a separate dialog
widget. But now, since we have a dedicated function to handle
this case, refactored the deactivation code to use the
'confirm_deactivation' function.
Additionally, created two new functions to handle the loading
spinner. Since we will need these functions in the future for
the "Manage Bot" modal, we marked them as exported.
"Since we do not want to show the 'Manage User' tab to the user
looking at their own profile, in the 'can_manage_user' function
that we use to render the 'Manage User' tab, we check if the user
profile popover belongs to the same user. If it does, we set it to
'false' instead of 'true,' ensuring that the 'Manage User' tab is
not visible.
Added a new tab in the user profile modal 'manage user'.
Fixes: #21806
If the owner of the bot is deactivated while reactivating the bot,
we mention in the reactivation modal that the bot owner will be
changed and the bot may be unsubscribed from some private streams.
Since `list_widget.render_item` accepts the parameter of type `Item` and
not `Key`, therefore we should pass the actual item instead of just
plain id to the `render_item` function here.
This is a prep commit for typescript migration of this module. In this commit
I made all the users of ListWidget pass generic sort functions like 'alphabetic'
and 'numeric' explicitly to avoid type conversions which we may need when moving
to typescript, also it simplifies our `set_sorting_function` a bit more.
Rename `get_active_human_ids` to `get_realm_active_human_user_ids`
to better fit naming conventions and to be more clear about the
detail that it only includes active users.
Fixes part of #25092.
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 removes the production reporting to `/json/report/error` upon
`blueslip.error`, and replaces it with reporting to Sentry, if
enabled. Sentry provides better reporting and grouping for exceptions
than the email- and `#errors`-reporting provided by the
`/json/report/error` endpoint.
The development behaviour of rendering `blueslip.error` messages and
stacktraces immediately, and stopping execution, is preserved.
To better chain exception information, the whole previous exception is
passed to `blueslip.error`, not just the stack, and the second
parameter is formalized to be an object to map to Sentry's "context"
concept.
Following the issue #23380 and PR #25038, this commit changes all
occurences of `uri` into `url` in all comments, local variables,
handlebars templates (.hbs) function names and their callers in
all `.js` and `.ts` files.
The code for hiding and showing email field in the user
deactiavtion modal was added in dialog_widget.js.
This commit removes it and instead add the code to its
relevant module (settings_user.js), since the email field
is present only in one modal and not all modals.
Close the user or bot popovers in Users, Deactivated users, bots tab of
Organization settings, on clicking Edit user button, Deactivate button
or Reactivate button.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <[email protected]>
