This changes the method of rendering list of alert words in DOM,
earlier it was rendered using 'for' loop over the array of alert_words
which is now changed to render using ListWidget, which gets a array
of objects from get_word_list() in alert_words.js.
The use of ListWidget helps to define a parent_container and $container
in table-body of alert-words-table using which we can now apply sorting over
alert words with the help of handle_sort() function in list_widget.js
Changed the method of adding alert_word_settings_item row in table body
through {{#with}} loop because of rendering through ListWidget, which was done
earlier using for loop over each alert-word in while rendering the list.
this commit also mocks template of render_alert_word_item
while mocking ListWidget.create() function in render_alert_words_ui().
and checks that ListWidget.create() is not called when variable `loaded`
is set as false.
Fixes#21142.
We refactor the code for user notification settings and realm-level
defaults of notification settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as separate
variables.
We refactor the code for user display settings and realm-level
defaults of display settings to pass a single object consisting
of container element, settings object, url and for_realm_settings
bool variable, to the functions, instead of passing them as
separate variables.
This commit creates a new module user_notification_settings.js
for user-level notification settings and the settings_notification.js
will be used as a common module for both user-level and realm-level
settings.
We also add parameters to the functions in settings_notifications.js
to pass container elem and settings object for the same purpose.
This commit adds a new module settings_defaults.js which calls
the functions in settings_display passing appropriate container
element and settings object as parameters.
We also add one more parameter for_realm_settings to some of the
functions in settings_dislay to differentiate between the user
and realm-level settings.
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).
jai2201
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