This commit refactors the code in settings_display.js
by modifying the functions to receive the container
element and settings object as parameter such that
we can use the same functions for realm-level
settings by passing appropriate container element
and settings object.
This change is needed as settings_display will be
used as a common module for user settings and realm
level settings.
We also rename the default_language_name variable in
settings_display to user_default_language_name as we
would add a separate variable for realm-level setting
in future.
We separate "Your account" section to two different sections -
"Profile" section for user name, custom profile fields, and avatar
and "Account & Security" section for email, password, role, api-key
and deactivating button.
Another important change here is that the modal for changing name
is removed and now the name has a simple input text box and it
behaves similar to inputs for custom-profile-fields.
Fixes#18848.
Adds a setting UI to list all configured playgrounds
in a realm. The filter functionality can be used to
search playgrounds by its name or language.
Default sort is provided on the 'pygments_language'
field.
Front tests added to maintain server_event_dispatch
coverage. The `settings_playgrounds.js` file is added
to coverage exclusion list since it is majorly UI
based and will be tested using puppeteer tests (in
following commits).
ES and TypeScript modules are strict by default and don’t need this
directive. ESLint will remind us to add it to new CommonJS files and
remove it from ES and TypeScript modules.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We no longer use `/json/users` in the codepath
for bot settings (admin side).
We also specifically don't load human users when
we load bots, so you no longer have to pay for
the server round trip as a side effect of loading
bots. Instead, there is a dedicated `set_up_bots`
entry point.
We also get the bot ids directly from `bot_data` now.
This commit, to some degree, builds on the prior commit
that had us hydrate data from `people.js` instead
of the payload from `/json/users`.
We don't really need to know whether we've loaded
the user-related panels, since we only used `meta.loaded`
for a tiny optimization to avoid a jQuery lookup.
We rely mostly on the list widgets from `list_render`,
and they are smart enough to repopulate themselves
when they're called subsequent times.
This commit was originally automatically generated using `tools/lint
--only=eslint --fix`. It was then modified by tabbott to contain only
changes to a set of files that are unlikely to result in significant
merge conflicts with any open pull request, excluding about 20 files.
His plan is to merge the remaining changes with more precise care,
potentially involving merging parts of conflicting pull requests
before running the `eslint --fix` operation.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
With webpack, variables declared in each file are already file-local
(Global variables need to be explicitly exported), so these IIFEs are
no longer needed.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
We move all of its logic into settings_sections.
Note that this is slightly more than a refactor.
We are slightly more aggressive about resetting
sections. For example, if you go into Settings,
then exit the overlay, then go into Manage
Organization, we will now reset sections for both
groups.
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
We now wait to load Organization sections until you
click on the section (or virtually click by using arrow
keys).
Some of the sections are coupled in terms of their setup,
so some sections will already be loaded if you had clicked
on a related section.
For the settings UI, we now wait until a user goes to a particular
settings section before calling the appropriate function to set
up the section (which usually involves setting up click handlers
and populating initial data).
Sahil Batra
sahil839
Abhijeet Prasad Bodas
Sumanth V Rao
Anders Kaseorg
Steve Howell
Anders Kaseorg
Wyatt Hoodes
Thomas Ip
Tim Abbott
Steve Howell
Armaan Ahluwalia
Shubham Dhama
Steve Howell