Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/static/templates/admin_bot_form.hbs

29 lines
1.6 KiB
Handlebars
Raw Normal View History

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
<div id="admin-bot-form" class="modal modal-bg hide fade" tabindex="-1" role="dialog" aria-labelledby="admin-bot-form-label" aria-hidden="true">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal" aria-label="{{t 'Close' }}"><span aria-hidden="true">&times;</span></button>
<h3 id="admin-bot-form-label">{{t "Change bot info and owner" }}</h3>
</div>
<div class="modal-body">
<div id="user-name-form" data-user-id="{{user_id}}">
<form class="form-horizontal name-setting">
<input type="hidden" name="is_full_name" value="true" />
<div class="input-group name_change_container">
<label for="full_name">{{t "Full name" }}</label>
<input type="text" autocomplete="off" name="full_name" value="{{ full_name }}" />
</div>
<div class="input-group email_change_container">
<label for="email">{{t "Email" }}</label>
<input type="text" autocomplete="off" name="email" value="{{ email }}" readonly/>
</div>
<div class="input-group edit_bot_owner_container">
<label for="bot_owner_select">{{t "Owner" }}</label>
</div>
</form>
</div>
</div>
<div class="modal-footer">
<button type="submit" class="button rounded sea-green submit_bot_change">{{t 'Save changes' }}</button>
<button type="button" class="button rounded" data-dismiss="modal">{{t "Cancel" }}</button>
</div>
</div>