zulip/static/js/settings_users.js

692 lines
22 KiB
JavaScript
Raw Normal View History

import $ from "jquery";
import render_admin_bot_form from "../templates/settings/admin_bot_form.hbs";
import render_admin_human_form from "../templates/settings/admin_human_form.hbs";
import render_admin_user_list from "../templates/settings/admin_user_list.hbs";
import render_settings_deactivation_user_modal from "../templates/settings/deactivation_user_modal.hbs";
import * as blueslip from "./blueslip";
import * as bot_data from "./bot_data";
import * as channel from "./channel";
import * as confirm_dialog from "./confirm_dialog";
import {DropdownListWidget as dropdown_list_widget} from "./dropdown_list_widget";
import {$t, $t_html} from "./i18n";
import * as ListWidget from "./list_widget";
import * as loading from "./loading";
import * as overlays from "./overlays";
import {page_params} from "./page_params";
import * as people from "./people";
import * as presence from "./presence";
import * as settings_account from "./settings_account";
import * as settings_bots from "./settings_bots";
import * as settings_config from "./settings_config";
import * as settings_data from "./settings_data";
import * as settings_panel_menu from "./settings_panel_menu";
import * as settings_ui from "./settings_ui";
import * as timerender from "./timerender";
import * as ui from "./ui";
import * as ui_report from "./ui_report";
import * as user_pill from "./user_pill";
const section = {
active: {},
deactivated: {},
bots: {},
};
function compare_a_b(a, b) {
if (a > b) {
return 1;
} else if (a === b) {
return 0;
}
return -1;
}
function sort_email(a, b) {
const email_a = settings_data.email_for_user_settings(a) || "";
const email_b = settings_data.email_for_user_settings(b) || "";
return compare_a_b(email_a.toLowerCase(), email_b.toLowerCase());
}
function sort_bot_email(a, b) {
function email(bot) {
return (bot.display_email || "").toLowerCase();
}
return compare_a_b(email(a), email(b));
}
function sort_role(a, b) {
return compare_a_b(a.role, b.role);
}
function sort_bot_owner(a, b) {
function owner_name(bot) {
return (bot.bot_owner_full_name || "").toLowerCase();
}
return compare_a_b(owner_name(a), owner_name(b));
}
function sort_last_active(a, b) {
return compare_a_b(
presence.last_active_date(a.user_id) || 0,
presence.last_active_date(b.user_id) || 0,
);
}
function get_user_info_row(user_id) {
return $(`tr.user_row[data-user-id='${CSS.escape(user_id)}']`);
}
function update_view_on_deactivate(row) {
const button = row.find("button.deactivate");
const user_role = row.find(".user_role");
button.prop("disabled", false);
row.find("button.open-user-form").hide();
row.find("i.deactivated-user-icon").show();
button.addClass("btn-warning reactivate");
button.removeClass("deactivate btn-danger");
button.html("<i class='fa fa-user-plus' aria-hidden='true'></i>");
button.attr("title", "Reactivate");
row.addClass("deactivated_user");
if (user_role) {
const user_id = row.data("user-id");
user_role.text(
"%state (%role)"
.replace("%state", $t({defaultMessage: "Deactivated"}))
.replace("%role", people.get_user_type(user_id)),
);
}
}
function update_view_on_reactivate(row) {
const button = row.find("button.reactivate");
const user_role = row.find(".user_role");
row.find("button.open-user-form").show();
row.find("i.deactivated-user-icon").hide();
button.addClass("btn-danger deactivate");
button.removeClass("btn-warning reactivate");
button.attr("title", "Deactivate");
button.html('<i class="fa fa-user-times" aria-hidden="true"></i>');
row.removeClass("deactivated_user");
if (user_role) {
const user_id = row.data("user-id");
user_role.text(people.get_user_type(user_id));
}
}
function get_status_field() {
const current_tab = settings_panel_menu.org_settings.current_tab();
switch (current_tab) {
case "deactivated-users-admin":
return $("#deactivated-user-field-status").expectOne();
case "user-list-admin":
return $("#user-field-status").expectOne();
case "bot-list-admin":
return $("#bot-field-status").expectOne();
default:
throw new Error("Invalid admin settings page");
}
}
function failed_listing_users() {
loading.destroy_indicator($("#subs_page_loading_indicator"));
const status = get_status_field();
const user_id = people.my_current_user_id();
blueslip.error("Error while listing users for user_id " + user_id, status);
}
function populate_users() {
const active_user_ids = people.get_active_human_ids();
const deactivated_user_ids = people.get_non_active_human_ids();
if (active_user_ids.length === 0 && deactivated_user_ids.length === 0) {
failed_listing_users();
}
section.active.create_table(active_user_ids);
section.deactivated.create_table(deactivated_user_ids);
}
function reset_scrollbar($sel) {
return function () {
ui.reset_scrollbar($sel);
};
}
function bot_owner_full_name(owner_id) {
if (!owner_id) {
return undefined;
}
const bot_owner = people.get_by_user_id(owner_id);
if (!bot_owner) {
return undefined;
}
return bot_owner.full_name;
}
function bot_info(bot_user_id) {
const bot_user = bot_data.get(bot_user_id);
if (!bot_user) {
return undefined;
}
const owner_id = bot_user.owner_id;
const info = {};
info.is_bot = true;
info.is_active = bot_user.is_active;
info.user_id = bot_user.user_id;
info.full_name = bot_user.full_name;
info.bot_owner_id = owner_id;
// Convert bot type id to string for viewing to the users.
info.bot_type = settings_bots.type_id_to_string(bot_user.bot_type);
info.bot_owner_full_name = bot_owner_full_name(owner_id);
if (!info.bot_owner_full_name) {
info.no_owner = true;
info.bot_owner_full_name = $t({defaultMessage: "No owner"});
}
info.is_current_user = false;
info.can_modify = page_params.is_admin;
// It's always safe to show the fake email addresses for bot users
info.display_email = bot_user.email;
return info;
}
2020-05-08 15:09:21 +02:00
function get_last_active(user) {
const last_active_date = presence.last_active_date(user.user_id);
if (!last_active_date) {
return $t({defaultMessage: "Unknown"});
2020-05-08 15:09:21 +02:00
}
return timerender.render_now(last_active_date).time_str;
}
function human_info(person) {
const info = {};
info.is_bot = false;
info.user_role_text = people.get_user_type(person.user_id);
info.is_active = people.is_person_active(person.user_id);
info.user_id = person.user_id;
info.full_name = person.full_name;
info.bot_owner_id = person.bot_owner_id;
2020-05-08 15:09:21 +02:00
info.can_modify = page_params.is_admin;
info.is_current_user = people.is_my_user_id(person.user_id);
info.cannot_deactivate = info.is_current_user || (person.is_owner && !page_params.is_owner);
2020-05-08 15:09:21 +02:00
info.display_email = settings_data.email_for_user_settings(person);
if (info.is_active) {
2020-05-08 15:09:21 +02:00
// TODO: We might just want to show this
// for deactivated users, too, even though
// it might usually just be undefined.
info.last_active_date = get_last_active(person);
}
return info;
}
let bot_list_widget;
section.bots.create_table = () => {
loading.make_indicator($("#admin_page_bots_loading_indicator"), {text: "Loading..."});
const $bots_table = $("#admin_bots_table");
$bots_table.hide();
const bot_user_ids = bot_data.all_user_ids();
bot_list_widget = ListWidget.create($bots_table, bot_user_ids, {
name: "admin_bot_list",
get_item: bot_info,
modifier: render_admin_user_list,
html_selector: (item) => `tr[data-user-id='${CSS.escape(item)}']`,
filter: {
element: $bots_table.closest(".settings-section").find(".search"),
predicate(item, value) {
if (!item) {
return false;
}
return (
item.full_name.toLowerCase().includes(value) ||
item.display_email.toLowerCase().includes(value)
);
},
onupdate: reset_scrollbar($bots_table),
},
2019-08-15 07:33:31 +02:00
parent_container: $("#admin-bot-list").expectOne(),
init_sort: ["alphabetic", "full_name"],
sort_fields: {
email: sort_bot_email,
bot_owner: sort_bot_owner,
},
simplebar_container: $("#admin-bot-list .progressive-table-wrapper"),
});
2019-08-15 07:33:31 +02:00
loading.destroy_indicator($("#admin_page_bots_loading_indicator"));
$bots_table.show();
};
section.active.create_table = (active_users) => {
const $users_table = $("#admin_users_table");
ListWidget.create($users_table, active_users, {
name: "users_table_list",
get_item: people.get_by_user_id,
modifier(item) {
2020-05-08 15:09:21 +02:00
const info = human_info(item);
return render_admin_user_list(info);
},
filter: {
element: $users_table.closest(".settings-section").find(".search"),
filterer: people.filter_for_user_settings_search,
onupdate: reset_scrollbar($users_table),
},
parent_container: $("#admin-user-list").expectOne(),
init_sort: ["alphabetic", "full_name"],
sort_fields: {
email: sort_email,
last_active: sort_last_active,
role: sort_role,
},
simplebar_container: $("#admin-user-list .progressive-table-wrapper"),
});
loading.destroy_indicator($("#admin_page_users_loading_indicator"));
$("#admin_users_table").show();
};
section.deactivated.create_table = (deactivated_users) => {
const $deactivated_users_table = $("#admin_deactivated_users_table");
ListWidget.create($deactivated_users_table, deactivated_users, {
name: "deactivated_users_table_list",
get_item: people.get_by_user_id,
modifier(item) {
2020-05-08 15:09:21 +02:00
const info = human_info(item);
return render_admin_user_list(info);
},
filter: {
element: $deactivated_users_table.closest(".settings-section").find(".search"),
filterer: people.filter_for_user_settings_search,
onupdate: reset_scrollbar($deactivated_users_table),
},
parent_container: $("#admin-deactivated-users-list").expectOne(),
init_sort: ["alphabetic", "full_name"],
sort_fields: {
email: sort_email,
role: sort_role,
},
simplebar_container: $("#admin-deactivated-users-list .progressive-table-wrapper"),
});
loading.destroy_indicator($("#admin_page_deactivated_users_loading_indicator"));
$("#admin_deactivated_users_table").show();
};
export function update_bot_data(bot_user_id) {
if (!bot_list_widget) {
return;
}
bot_list_widget.render_item(bot_user_id);
}
export function update_user_data(user_id, new_data) {
const user_row = get_user_info_row(user_id);
if (user_row.length === 0) {
return;
}
if (new_data.full_name !== undefined) {
// Update the full name in the table
user_row.find(".user_name").text(new_data.full_name);
}
if (new_data.is_active !== undefined) {
if (new_data.is_active === false) {
// Deactivate the user/bot in the table
update_view_on_deactivate(user_row);
} else {
// Reactivate the user/bot in the table
update_view_on_reactivate(user_row);
}
}
if (new_data.role !== undefined) {
user_row.find(".user_role").text(people.get_user_type(user_id));
}
}
function start_data_load() {
loading.make_indicator($("#admin_page_users_loading_indicator"), {text: "Loading..."});
loading.make_indicator($("#admin_page_deactivated_users_loading_indicator"), {
text: "Loading...",
});
$("#admin_deactivated_users_table").hide();
$("#admin_users_table").hide();
populate_users();
}
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
function open_human_form(person) {
const user_id = person.user_id;
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const html = render_admin_human_form({
user_id,
email: person.email,
full_name: person.full_name,
user_role_values: settings_config.user_role_values,
disable_role_dropdown: person.is_owner && !page_params.is_owner,
});
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const div = $(html);
const modal_container = $("#user-info-form-modal-container");
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
modal_container.empty().append(div);
overlays.open_modal("#admin-human-form");
$("#user-role-select").val(person.role);
if (!page_params.is_owner) {
$("#user-role-select")
.find(`option[value="${CSS.escape(settings_config.user_role_values.owner.code)}"]`)
.hide();
}
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const element = "#admin-human-form .custom-profile-field-form";
$(element).html("");
settings_account.append_custom_profile_fields(element, user_id);
settings_account.initialize_custom_date_type_fields(element);
const pills = settings_account.initialize_custom_user_type_fields(
element,
user_id,
true,
false,
);
return {
modal: div,
fields_user_pills: pills,
};
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
}
function get_human_profile_data(fields_user_pills) {
/*
This formats custom profile field data to send to the server.
See render_admin_human_form and open_human_form
to see how the form is built.
TODO: Ideally, this logic would be cleaned up or deduplicated with
the settings_account.js logic.
*/
const new_profile_data = [];
$("#admin-human-form .custom_user_field_value").each(function () {
// Remove duplicate datepicker input element generated flatpicker library
if (!$(this).hasClass("form-control")) {
new_profile_data.push({
id: Number.parseInt(
$(this).closest(".custom_user_field").attr("data-field-id"),
10,
),
value: $(this).val(),
});
}
});
// Append user type field values also
for (const [field_id, field_pills] of fields_user_pills) {
if (field_pills) {
const user_ids = user_pill.get_user_ids(field_pills);
new_profile_data.push({
id: field_id,
value: user_ids,
});
}
}
return new_profile_data;
}
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
function open_bot_form(person) {
const html = render_admin_bot_form({
user_id: person.user_id,
email: person.email,
full_name: person.full_name,
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
});
const div = $(html);
const modal_container = $("#user-info-form-modal-container");
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
modal_container.empty().append(div);
overlays.open_modal("#admin-bot-form");
// NOTE: building `owner_dropdown` is quite expensive!
const owner_id = bot_data.get(person.user_id).owner_id;
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const user_ids = people.get_active_human_ids();
const users_list = user_ids.map((user_id) => ({
name: people.get_full_name(user_id),
value: user_id.toString(),
}));
const opts = {
widget_name: "edit_bot_owner",
data: users_list,
default_text: $t({defaultMessage: "No owner"}),
value: owner_id,
};
const owner_widget = dropdown_list_widget(opts);
return {
modal: div,
owner_widget,
};
}
function confirm_deactivation(row, user_id, status_field) {
const user = people.get_by_user_id(user_id);
const modal_parent = $("#admin-user-list");
const opts = {
username: user.full_name,
email: user.email,
};
const html_body = render_settings_deactivation_user_modal(opts);
function handle_confirm() {
const row = get_user_info_row(user_id);
const row_deactivate_button = row.find("button.deactivate");
row_deactivate_button.prop("disabled", true).text($t({defaultMessage: "Working…"}));
const opts = {
success_continuation() {
update_view_on_deactivate(row);
},
error_continuation() {
row_deactivate_button.text($t({defaultMessage: "Deactivate"}));
},
};
const url = "/json/users/" + encodeURIComponent(user_id);
settings_ui.do_settings_change(channel.del, url, {}, status_field, opts);
}
confirm_dialog.launch({
parent: modal_parent,
html_heading: $t_html({defaultMessage: "Deactivate {email}"}, {email: user.email}),
html_body,
html_yes_button: $t_html({defaultMessage: "Confirm"}),
on_click: handle_confirm,
});
}
function handle_deactivation(tbody, status_field) {
tbody.on("click", ".deactivate", (e) => {
// This click event must not get propagated to parent container otherwise the modal
// will not show up because of a call to `close_active_modal` in `settings.js`.
e.preventDefault();
e.stopPropagation();
const row = $(e.target).closest(".user_row");
const user_id = row.data("user-id");
confirm_deactivation(row, user_id, status_field);
});
}
function handle_bot_deactivation(tbody, status_field) {
tbody.on("click", ".deactivate", (e) => {
e.preventDefault();
e.stopPropagation();
const button_elem = $(e.target);
const row = button_elem.closest(".user_row");
const bot_id = Number.parseInt(row.attr("data-user-id"), 10);
const url = "/json/bots/" + encodeURIComponent(bot_id);
const opts = {
success_continuation() {
update_view_on_deactivate(row);
},
error_continuation(xhr) {
ui_report.generic_row_button_error(xhr, button_elem);
},
};
settings_ui.do_settings_change(channel.del, url, {}, status_field, opts);
});
}
function handle_reactivation(tbody, status_field) {
tbody.on("click", ".reactivate", (e) => {
e.preventDefault();
e.stopPropagation();
// Go up the tree until we find the user row, then grab the email element
const button_elem = $(e.target);
const row = button_elem.closest(".user_row");
const user_id = Number.parseInt(row.attr("data-user-id"), 10);
const url = "/json/users/" + encodeURIComponent(user_id) + "/reactivate";
const data = {};
const opts = {
success_continuation() {
update_view_on_reactivate(row);
},
error_continuation(xhr) {
ui_report.generic_row_button_error(xhr, button_elem);
},
};
settings_ui.do_settings_change(channel.post, url, data, status_field, opts);
});
}
function handle_human_form(tbody, status_field) {
tbody.on("click", ".open-user-form", (e) => {
e.stopPropagation();
e.preventDefault();
const user_id = Number.parseInt($(e.currentTarget).attr("data-user-id"), 10);
const person = people.get_by_user_id(user_id);
if (!person) {
return;
}
const ret = open_human_form(person);
const modal = ret.modal;
const fields_user_pills = ret.fields_user_pills;
modal.find(".submit_human_change").on("click", (e) => {
e.preventDefault();
e.stopPropagation();
const role = Number.parseInt(modal.find("#user-role-select").val().trim(), 10);
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const full_name = modal.find("input[name='full_name']");
const profile_data = get_human_profile_data(fields_user_pills);
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const url = "/json/users/" + encodeURIComponent(user_id);
const data = {
full_name: JSON.stringify(full_name.val()),
role: JSON.stringify(role),
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
profile_data: JSON.stringify(profile_data),
};
settings_ui.do_settings_change(channel.patch, url, data, status_field);
overlays.close_modal("#admin-human-form");
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
});
});
}
function handle_bot_form(tbody, status_field) {
tbody.on("click", ".open-user-form", (e) => {
e.stopPropagation();
e.preventDefault();
const user_id = Number.parseInt($(e.currentTarget).attr("data-user-id"), 10);
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
const bot = people.get_by_user_id(user_id);
if (!bot) {
return;
}
const {modal, owner_widget} = open_bot_form(bot);
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
modal.find(".submit_bot_change").on("click", (e) => {
user settings: Separate code for bot form. When editing a bot, there are only two fields that are similar to humans--full name and email--which are trivial. Before this commit we used a single codepath to build the human form and the bot form. Now we have two simple codepaths. The tricky nature of the code had already led to ugly things for the bot codepath that fortunately weren't user facing, but which were distracting: - For bots we would needlessly set things like is_admin, is_guest in the template data. - For bots we would needlessly try to update custom profile fields. The code that differs between bots and humans is nontrivial, and the code was both hard to read and hard to improve: - Humans don't have bot owners. - Bots don't have custom profile fields. The bot-owner code is nontrivial for performance reasons. In a big realm there are tens of thousands of potential bot owners. We avoid the most egregious performance problems (i.e we don't have multiple copies of the dropdown), but we may still want to refine that (at least adding a spinner). The custom-profile-fields code is nontrivial due to the dynamic nature of custom profile fields, which can bring in specialized widgets like pill fields. Now each form corresponds to a single endpoint: * human -> /json/users * bot -> /json/bots Before we had a lot of conditional logic in the template, the code to build to views, and the code to submit the data. Now everything is much flatter. The human code is still a bit messy (more work coming on that), but the bot code is fairly pristine. All three components of the bot code fit on a page, and there are no conditionals: - admin_bot_form.hbs - open_bot_form - handle_bot_form We may want to grow out the bot code a bit to allow admins to do more things, such as adding services, and this will be easier now. It would also be easier for us now to share widgets with the per-user bot settings. Note that the form for editing human data will continue to be invoked from two panels: - Users - Deactivated users There are some minor differences between users and deactivated users, but the shape of the data is the same for both, so that's still all one codepath. We eliminate `reset_edit_user` here, since it was never used. One nice thing about these forms was that they had very little custom CSS attached to them (at form-level specificity), and it turned out all the custom CSS was for the human-specific form.
2020-05-09 12:13:03 +02:00
e.preventDefault();
e.stopPropagation();
const full_name = modal.find("input[name='full_name']");
const url = "/json/bots/" + encodeURIComponent(user_id);
const data = {
full_name: full_name.val(),
};
const human_user_id = owner_widget.value();
if (human_user_id) {
data.bot_owner_id = human_user_id;
}
settings_ui.do_settings_change(channel.patch, url, data, status_field);
overlays.close_modal("#admin-bot-form");
});
});
}
section.active.handle_events = () => {
const tbody = $("#admin_users_table").expectOne();
const status_field = $("#user-field-status").expectOne();
handle_deactivation(tbody, status_field);
handle_reactivation(tbody, status_field);
handle_human_form(tbody, status_field);
};
section.deactivated.handle_events = () => {
const tbody = $("#admin_deactivated_users_table").expectOne();
const status_field = $("#deactivated-user-field-status").expectOne();
handle_deactivation(tbody, status_field);
handle_reactivation(tbody, status_field);
handle_human_form(tbody, status_field);
};
section.bots.handle_events = () => {
const tbody = $("#admin_bots_table").expectOne();
const status_field = $("#bot-field-status").expectOne();
handle_bot_deactivation(tbody, status_field);
handle_reactivation(tbody, status_field);
handle_bot_form(tbody, status_field);
};
export function set_up_humans() {
start_data_load();
section.active.handle_events();
section.deactivated.handle_events();
}
export function set_up_bots() {
section.bots.handle_events();
section.bots.create_table();
}