This is a direct code move which puts all the functions
related to `user_id` lists near the bottom of the file.
This will make the file slightly easier to read.
Long labels like "Yes, Unsubscribe this stream" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm".
Fixes#17926.
Previously, realm emojis can override default emojis in emoji-picker,
if the user sets an exisitng emoji name to his/her custom emoji.
For clear understanding--
If a user sets an realm emoji with name `smile`, this leads to the
newly realm emoji override the existing default emoji `smile`.
To address such behaviour, Added a warning modal which requires
the user confirmation before overriding the default emoji.
Fixes#16913.
Moved `admin_user_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Fixes#18227
Moved `admin_user_group_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.
Also modified the node tests to reflect the new changes.
Moved `admin_tab` 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_settings_modals` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_linkifier_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_invites_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_human_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_export_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_emoji_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.
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 reverses the policy that was set, but incompletely enforced, by
commit 951514dd7d. The self-closing tag
syntax is clearer, more consistent, simpler to parse, compatible with
XML, preferred by Prettier, and (most importantly now) required by
FormatJS.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
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.
This is both more correct and also fixes this element having had a
name very similar to message_control_button, which refers to an
element in the message_controls section of a rendered message.
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.
The unicode horizontal ellipsis is visually nicer.
b40e50f295 removed many of these,
by changing the text itself.
This commit handles the remaining few.
Since all the message reactions are inserted before the
add reaction button, if it is the first child, we can safely
remove it.
We changed this from `only-child` to be `first-child` because
we append tooltips as siblings of `reaction_button` but since
they are appended, they are always appended after the `reaction_button`.
Thus, if there were tooltips present the reaction_button won't hide.
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.
I have added a documentation page for the GitHub Actions integration to
`/integrations/doc/github-actions` with a link to the Zulip GitHub
Actions repository.
Tweaked by tabbott to add cross-links with the main GitHub integration.
I have updated any missing bot avatars after running the tool whilst
creating integrations. These needed adding otherwise the tool creates
them whenever it is ran.
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(),
);
}
We use an inverted color scheme to what we use for unread messages, so
that one's eyes scan these as different from unreads.
We also need to introduce a 1px offset because the border takes up space.
Fixes#17938.
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.
We had a mix of the two names, and "video call provider" both feels
more professional and more clear about precisely what it does.
We don't change the API fields, since it doesn't seem worth an API
migration.
Abhijeet Prasad Bodas
sahil839
nikhilmaske-2001
Tim Abbott
aryanshridhar
Anders Kaseorg
PIG208
Aman Agrawal
scjess
akshatdalton
Nikhil Maske
Gaurav Pandey
Mateusz Mandera
Sumanth V Rao
Wesley Aptekar-Cassels
m-e-l-u-h-a-n
ryanreh99
Vishnu KS
Steve Howell
Adam Birds
Signior-X