This helps us consolidate the fetching constants without
having to export them. It will also remove some
responsibility for narrow.js to track fetching state.
Till now, we had been storing realm emoji's name in emoji code field
in reactions' model. This commit migrates it to store realm emoji's id.
It is a part of effort to migrate realm emojis to be referenced by their
id and not by name.
The former "the-bot-is-being-created" indicator was useless,
since it only edited the value attribute of the "create-bot" button;
that attribute only sets the text of a button when it is initially created.
This commit replaces the old code with a spinning loading indicator,
like the one used for editing bots.
This effectively changes a condition from `=== 0` to `<= 0`,
but that probably doesn't matter (and would only help). More
importantly, it just makes the code more consistent.
This mostly moves code from ui.js.
We change the arguments to `message_fetch.load_more_messages()`
to be `opts` with callbacks for `show_loading` and `hide_loading`.
We also defer starting the scroll handler until `message_fetch.js`
has been initialized.
To prevent specifying notifications individually for global
updates, automate handle_global_notification_updates using
settings_notifications.notification_settings where we have
the keys of all the types of notifications.
If we have bugs in our compose code, we don't want them to
cause other strange side effects during reload. (We recently
had a test deployment that was a bit buggy, and the reload
problem was tough to chase down due to the misleading
symptoms.)
@brockwhittaker wrote the original prototype for having
pills in the recipient box when users compose PMs (either
1:1 or huddle). The prototype was test deloyed on our
main realm for several weeks.
This commit includes all the original CSS and HTML from
the prototype.
After some things changed with the codebase after the initial
test deployment, I made the following changes:
* In prior commits I refactored out a module called
`user_pill.js` that implemented some common functions
against a more streamlined version of `input_pill.js`,
and this commit largely integrates with that.
* I made changes in a prior commit to handle Zephyr
semantics (emails don't get validated) and tested
this commit with zephyr.
* I fixed a reload bug by extracting code out to
`compose_pm_pill.js` and re-ordering some
calls to `initialize`.
There are still two flaws related to un-pill-ified text in the
input:
* We could be more aggressive about trying to pill-ify
emails when you blur or tab away.
* We only look at the pills when you send the message,
instead of complaining about the un-pill-ified text.
(Some folks may consider that a feature, but it's
probably surprising to others.)
The main point of this change is to streamline the core
code for input pills, and we use also modify user groups.
The main change to input_pill.js is that you now
configure a function called `create_item_from_text`, and
that can return an arbitrary object, and it just needs
a field called `display_value`.
Other changes:
* You now call `input.create(opts)` to create the
widget.
* There is no longer a cache, because we can
write smarter code in typeahead `source` functions
that exclude ids up front.
* There is no value/optinalKey complexity, because
the calling code can supply arbitrary objects and
do their own external data management on the pill
items.
* We eliminate `prependPill`.
* We eliminate `data`, `keys`, and `values`, and just
have `items`.
This split notification settings to separate settings for streams,
PM/mention and other notifications settings.
Previously we have to treat them combined, but with this refactor,
we can treat them separately for future changes.
Fixes#8587.
Until page gets load, table lists are empty. Which results in
showing empty-data-text("No data match to search query") in
setting page parallel to loading spinner.
Hide table-list and show loading spniner until
setting page and table-list gets load.
In org settings, loading spinners are not visible, currently
because their size is very small.
Fix this, by increasing width and height of spinners and
adding spinner text, to make spinners more visible.
Fixes#8502
In `recipient-row` template, if conditions to add/hide/show edit
icon for message topic is incorrect.
In some cases, we only want to just hide the edit icon, but icon
should be in DOM, cause in future if organization settings are
changed we want to show edit icon in message row.
If user can edit topic of message, surely add edit icon element to
DOM regardless of user is allowed to edit or not. If user is
allowed to edit then show edit icon otherwise hide edit icon element.
`update_message_topic_editing_pencil` function update edit
icon for message topic in message row header.
- Remove erroneous `meta.loaded` check.
- Add proper check of message editing permission in realm
before updating message-topic-edit-icon in function.
- Update `always-visible-topic-edit` element in function
simultaneously.
Rename `toggle_allow_message_editing_pencil` to
`update_message_topic_editing_pencil` in `settings_org.js`.
As this function update the pencil icon for updating message
topic in message row header.
We fallback to using data-user-email attrib for mention messages
from the times when we use to expose user emails to frontend.
This is only required for cases where we are dealing with anything
that isn't rendered dynamically (like the messages that were already
sent and stored long time ago). Hopefully we won't be needing this
kind of fallback logic in more places so I am putting off efforts
to try to extract fallback logic for common use. Also this is like
this because it will probably be tricky to extract out a common
fallback logic in this case because of different situations involved.
Fixes: #8588.
This provides a slightly clearer interface, allowing us to remove the
unnecessary split of the code for the clone_file_input concept across
multiple modules (we now just clone it on-demand).
This makes it easier for users to tell how Zulip ended up with an
avatar for them without them uploading one: through the Gravatar
service used across many Wordpress blogs.
Fixes#8225.
In stream deactivation modal, make "stream_name" a template variable,
rather than patching stream name to modal header in javascript.
Add tests for deactivation stream modal.
