Moved `admin_default_stream_list` template to `/templates/settings/`
folder as earlier, it was inaccurately placed within the `/templates`
folder and should have been within the `/templates/settings` folder
instead.
Moved `admin_bot_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and `settings` folder is specifically for storing administrative
UI templates.
This involves in two changes for styling.
1. The alert class is moved from alert.css to app_components.css as this
class serves nothing but to default .alert elements to be hidden. This
is only required in the webapp but not portico pages (where .alert
elements are preferred to be shown by default).
2. The import statement for alert.css is moved from app.js to common.js,
so that both the webapp and the portico pages can share the styles. This
will be fine to share the styles as .alert-display, .alert-animations,
.alert-box are more specific then .alert and they use nested class to
define styles for inner elements.
Undoes #17936 properly.
This improves the UX of creating a stream for atleast 1000+ users
realm by showing the the stream creation form much faster than
before.
Search, user addition, scrolling worked smoothly on 15k+
users realm as tested on dev setup.
Also, simplebar is used to replace the default scrollbar.
Fixes#16805
When moving a topic within a stream that is deactivated, the stream
may not be present in stream_data. Avoid throwing an exception in
this situation by leaving stream_name as undefined; existing logic
seems to anticipate that as a possibility, so we don't need a broader
change.
Longer term, we may want to just send to clients basic data about
archived streams that the user has access to.
Fixes: #17271
This commit adds a helper function: `mute_or_unmute_topic`
in `click_handlers.js` to mute and unmute a topic. This function
is called when a user mutes/unmutes a topic from its recipient bar
or `recent topics`.
This is a prep commit for `Allow unmuting of a topic from its recipient bar`.
Related issue: #15223.
The bug happens in the case when the topic name is not set and the
user clicks on always_visible_topic_edit button results into unusual
behaviour of the always_visible_topic_edit button. To fix this, this
commit fix the behaviour by hiding and showing the
always_visible_topic_edit button in the appropiate situations, at the
same time we hide/show similar buttons.
Fixes#17813.
This allows us to use different "Show password" and "Hide password"
for these labels, which is more consistent with how other products
implement this.
It also lets us delete N duplicate copies of these strings in the HTML.
The "Save failed" standard text is appropriate for many of our
settings, but for changing one's password, we can go with just the
"Wrong password" part provided by the server.
The show password feature is a functionality to
toggle the visibility of the password fields in forms
so that one can check if they have entered the correct
password or not. We implement this using an eye icon
toggling which converts input field type from password
to text and vice-versa.
Fixes part of #17301.
This allows us to hide tooltips automatically when the
parent container is hidden while tooltip is active.
In an overlay, when a tooltip is active and `esc` is pressed,
the tooltip will remain active without this commit.
This has side effects of some properties of parent applying to
tooltips if property is directly set to `div`. Through manual testing,
only area where this was found was fixed.
We destroy the tooltips for which `reference` was either removed
from DOM or is hidden.
We only need to do this for tooltips
contained in simplebar containers for which tooltips can
overflow the boundary of the simplebar container.
There are 4 approaches we could have done this:
1. Asked tippy.js maintainers to do this for us.
In https://github.com/atomiks/tippyjs/issues/938 the
maintainer said that it is the responsibility of
the user to do so.
2. Tracked whenever we update the DOM for such elements and hide
tooltips when we were hiding the `reference` elements. This had
various problems like it is hard trigger events when certain elements have
been removed from DOM when `html()` method is used to render
new content.
3. Run an `optimized` periodic job to destroy tooltips when
`reference` elements are hidden. This isn't a good method to
do this since it sucks power and adds latency.
4. Use a `MutationObserver` on the parent element and watch
for changes. This methods seems to work well with no bad
side effects. We use this approach.
Instead of inserting tooltip inside `body`, we directly insert
it inside the `reference` element. This helps us to automatically
hide the tooltip when we hide the `reference` element.
This avoids the bug of tooltip persisting when the message reaction
is removed while the tooltip is active.
To reproduce:
* React 👍 to a message.
* Hover over the reaction.
* Press `+` from keyboard.
You will see reaction tooltip persisting while the reaction is hidden,
also "Add emoji" icon is displayed with tooltip.
Doing the same for elements which are inside a simplebar container
and for which tooltips can span outside the simplebar container,
makes the tooltips not visible or cut at the edges of simplebar
container since simplebar containers have overflow set to `hidden`.
This is something that cannot fixed as per
https://github.com/Grsmto/simplebar/issues/347
So, for simplebar contained elements we insert the tooltip to
`body`.
`reference` element: Element for which tooltip is displayed.
Since the "mute users" feature isn't complete yet,
this UI is shown only in development setups.
Ideally we should have had this commit after the whole
feature was completed and merged, but doing so makes it
difficult to test and merge subparts of the feature one by
one (which is a better workflow, while we still decide what
exactly we want this feature to do).
This commit adds a new button in the user info popover
to mute or unmute the user, and uses a confirmation
dialog while muting, because muting a user accidently can lead
to the muter losing out on a lot of information.
TODOs when making this UI visible in production-
1. Make a /help page and link to it from the confirmation
dialog and the API docs.
This extra commit adds support for creating user group pills
in cases that do not use typeahead like, pasting the group
name, copying it from the user group pill.
This completes the remaining work required to support
addition of all members of a user groups to stream.
Fixes#15186.
We update the pills typeahead logic to also include user group
results and pass the "user_group" key in `opts` to enable this
option for Add subscriber form.
The changes includes:
* Exporting the `query_matches_name_description` function, to
deduplicate the typeahead `matcher` logic.
* Creating a `people.is_known_user` function, to deduplicate
the typeahead `sorter` logic.
* Add a new `user_group_pill.js`, to allow adding user group
pills in input widgets that support pills.
This has been tested manually as well as by adding some new
node tests.
This commit removes`typeahead_helper.sort_recipientbox_typeahead`
which was introduced in 639ec9380a
for the private message recipient box when it used to accept comma
separated text input for recipients. All it doew was cleaning away
invalid recipients from string, like:
"a, , b" was cleaned to [a, b].
This can be now removed because it was now used only in
pill_typeahead.setup code path, and the pills code already handles
invalid cases by filtering out all falsy (invalid) recipients.
We move compose.html to compose.hbs file while keeping
`#compose` still in `home.html` as a hanger
where append rest of the elements.
This will provide us with two benefits:
* We could share common elements between message_edit_form and
compose.
* We can insert compose directly in any element. We may decide to
do it for recent topics.
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).
To prevent breaking of the hardcoded playgrounds, we resort
to checking if realm_playgrounds is empty and falling back
to the hard-coded list if so. This logic is removed in the
followup commit which introduces the UI to add a playground.
This is in preparation for moving this code to @zulip/shared for use in
the mobile app, where we will want to use Sentry for reporting errors,
rather than blueslip.
The way I've done this only allows for reporting one type of error
(currently, blueslip.warn), but seeing as we only have one place we
report an error, that seems like something we can fix if we want more
error levels at a later date.
This reduces the complexity of our dependency graph.
It also makes sub_store.get parallel to message_store.get.
For both you pass in the relevant id to get the
full validated object.
This breaks an indirect dependency of stream_data
on the channel module.
It's a verbatim code move, apart from the one-line
helper `has_history_for`. It's not totally clear
to me why the original code doesn't call into
`is_complete_for_stream_id` to early-exit, but
figuring that out is outside the scope of my
change.
It's possible that we will eventually just subsume
this tiny module into topic_list once we finish
breaking all dependencies, but we may want to
reuse this for something like Recent Topics
or other similar UIs.
It's also possible that we'll want to rename
stream_topic_history -> stream_topic_history_data
sometime soon, possibly after we clean up its
dependency on message_util soon.
We only update the `.private_messages_header` here since
unread_counts of `.expanded_private_message` are updated
via `pm_list.update_private_messages`.
This fixes the bug of PMs in `.expanded_private_message` having
the same unread count as `private_messages_header`.
Since we rerender the DOM of `.expanded_private_message` every
time we update unread count of PMs, we don't need to manually
update them here. Also, we always keep them on display since
there is no real need to toggle them. They are not visible
when they have 0 unread counts via `.zero_count`.
While rest of the app has ported to the new system of updating
unread_counts `activity` was not ported. This resulted in
unread count in buddy list not being updated when new
PMs arrive.
The series of commits to consolidate CSS classes
for the various unread-count spans across our app
created a bug where the stream_list.js code's selector
starting capturing the unread spans in topic list items.
Suppose you had a stream with these topics:
Foo 10
a 3
b 3
c 4
If another unread came in, you would briefly see:
Foo 11
a 11
b 11
c 11
Now we just use subscription_block to find the
element that we want to tweak.
I remove a convoluted node test here. Part of the
reason the node test was convoluted was that the
original implementation was overly complex. I will
try to re-introduce a simpler test soon, but this
is a bit of an emergency fix.
This reduces our dependency on message_list code (via
message_util), and it makes moving streams/topics and
deleting messages more performant.
For every single message that was being updated or
deleted, the previous code was basically re-computing
lots of things, including having to iterate through
every message in memory to find the messages matching
your topic.
Now everything basically happens in O(1) time.
The only O(N) computation is that we now lazily
re-compute the max message id every time you need it
for typeahead logic, and then we cache it for
subsequent use. The N here is the number of messages
that the particular sender has sent to the particular
stream/topic combination, so it should always be quite
small, except for certain spammy bots.
Once the max has been calculated, the common operation
of adding a message doesn't invalidate our cached
value. We only invalidate the cache on deletes.
The main change that we make here from a data
standpoint is that we just keep track of all
message_ids for all senders. The storage overhead here
should be negligible. By keeping track of our own
messages, we don't have to punt to other code for
update/delete situations.
There is similar code in recent_topics that I think can
be improved in similar ways, and it would allow us to
eliminate functions like this one:
export function get_messages_in_topic(stream_id, topic) {
return message_list.all
.all_messages()
.filter(
(x) =>
x.type === "stream" &&
x.stream_id === stream_id &&
x.topic.toLowerCase() === topic.toLowerCase(),
);
}
In an effort to use a common class to display unread counts across
the app, we simplify the elements used to show unreads and use a
single `span` with `unread_count` class to do so.
This commit replaces the "echo_data.orig_raw_content" with
"echo_data.raw_content" in "message_edit.js". If the user is editing
a message and it fails, all the edited data used to get lost. Now, the
new edited content appears so that the user does not lose his edited
content.
This bug has been present since the original #12145, where a
refactoring error resulted in using the pre-edit data.
Fixes#18142.
If you have two emojis of the same name, we were
trying to render the non-realm emoji without an
emoji_code, since the condition that I changed
here was erroneously just seeing if the name was
among the realm emojis.
This fix prevents a funny symptom that is reported
in #18135. The symptom is that the non-realm
emoji causes us to render the top-left emoji in
our sprite sheet, since we didn't put emoji_code
into the args.
This doesn't fix the fundamental problem that
having two emojis of the same name is extemely
confusing. Our markdown parser obviously can't
distinguish ":thank_you:" from ":thank_you:". For
the the typeahead case I suppose we could add some
kind of suffix.
So, this fix only simplifies debugging; it doesn't
get to the root of the problem.
KaTeX makes use of a "span.overlay" element for the little vector
arrow symbol on top of a `\vec` object. This conflicts with Zulip's
CSS for our overlays, which are divs with the `overlay` CSS class.
While KaTeX may rename their class
(https://github.com/KaTeX/KaTeX/issues/1456), we can work around this
issue by scoping our own overlay CSS and click handlers to
"div.overlay" rather than ".overlay".
Fixes#18068.
This commit adds a helper function named `handle_linkifier_api_error`
to `static/js/settings_linkifiers.js`. As the name suggests, this
function handles the error returned from the API, specifically
for operations on linkifiers (like adding linkifier).
This is a prep commit for `Add setting to edit linkifiers`.
Related issue: #10830.
The main motive to add this helper function is to avoid copying
substantial blocks of code, as it tends to result in someone later
fixing bugs in only one of the two places.
This reverts commit f81cc16a0f (#17999).
The {{#tr}} helper now includes the functionality that we wanted from
this.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We don’t extract either of these strings correctly at present, but I’m
about to replace the entire frontend extraction system.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Previously, when viewing the source of a locally-echoed (pending)
message, if one tried to copy-paste using the copy button, the
"Copied!" status was displayed but the message was not copied.
This was because as we use message ids with a . in then for locally
echoed messages, which ClipboardJS considered an error (invalid
selector).
To solve this
* Remove the data-clipboard-target attribute of copy button.
* Dynamically set target in ClipboardJS config
the based on message id using querySelector
with the message id written with CSS.escape.
Fixes#18053.
* This introduces a new event type `realm_linkifiers` and
a new key for the initial data fetch of the same name.
Newer clients will be expected to use these.
* Backwards compatibility is ensured by changing neither
the current event nor the /register key. The data which
these hold is the same as before, but internally, it is
generated by processing the `realm_linkifiers` data.
We send both the old and the new event types to clients
whenever the linkifiers are changed.
Older clients will simply ignore the new event type, and
vice versa.
* The `realm/filters:GET` endpoint (which returns tuples)
is currently used by none of the official Zulip clients.
This commit replaces it with `realm/linkifiers:GET` which
returns data in the new dictionary format.
TODO: Update the `get_realm_filters` method in the API
bindings, to hit this new URL instead of the old one.
* This also updates the webapp frontend to use the newer
events and keys.
This commit fixes the issue of error message not getting
displayed when the `Full name` field, in bots settings, is given
a duplicate name of an already created bot with the same name.
We were closing the modal each time whether the request is
successful or not. Hence, we now close the modal only
when the request is successful and error is displayed on
the modal otherwise.
Fixes#18091.
Previously, you had to request the `stream` event type in order to get
the stream-level parameters; this was a bad design in part because the
`subscription` event type has similar data and is preferred by most
clients.
So we move these to the `realm` object. We also add the maximum topic
length, as an adjacent parameter.
While changing this, we also fix these to better match the names of
similar API parameters.
Previously, clicking the codeblock copy button also
triggered the compose box to open.
This is because of the fact that ClipBoard.js lacks the
ability to stopPropogate the event when clicked.
Rectified by explicitly defining the copy click event
within `is_clickable_message_element`, which disallows
the triggering of reply box.
Effectively a workaround for
https://github.com/zenorocha/clipboard.js/pull/475.
Fixes#17861.
We'll get the same result by letting jQuery stringify these; so
explicit JSON encoding here is likely to just encourage contributors
to cargo-cult JSON-encode strings in the future.
* Don't require strings to be unnecessarily JSON-encoded.
* Use check_capped_string rather than custom code for length checks.
* Update frontend to pass the right parameters.
With a much simplified populate_data_for_request design suggested by
Anders; we only support a handful of data types, all of which are
correctly encoded automatically by jQuery.
Fixes part of #18035.
As zulip is tranfering its tooltip to tippy the
tooltips for subs sort options are tranfered to
use tippy instead of title. Placement is bottom.
Refer https://github.com/zulip/zulip/pull/17434.
If we are changing_hash, it means `window.location.hash` is the
new_hash, so we don't want to change hash further now.
This used to create a loop of changing hashes as we used to close
and open overlays if `hash_before_overlay` was an overlay.
Fixes#18011
This gives us information that browser hash has already changed
and now we are just showing the correct overlay. This can help us
make informative decision that if we want to change the hash back
to the last hash after closing the overlay or not.
aryanshridhar
Anders Kaseorg
PIG208
Aman Agrawal
scjess
akshatdalton
Nikhil Maske
Tim Abbott
Gaurav Pandey
Abhijeet Prasad Bodas
Mateusz Mandera
Sumanth V Rao
m-e-l-u-h-a-n
ryanreh99
Wesley Aptekar-Cassels
Steve Howell
Signior-X
tushar912
Aryan Shridhar
guptaprakhariitr