In a non interleaved view when composing a message to another
conversation we fade messages which the user is not replying to,
to reduce the chance they send a message to a recipient they didn't
intend to. Also, it reduces the visual/cognitive processing required
to figure out where their message is going to go.
But, it's not necessarily clear to users that what the
fading means, so this commit adds a one-time compose banner
to explain what's going on the first time this comes up.
Fixes part of #29076.
Earlier in search suggestion, has: operator returned two different
suggestion string which were `messages with one or more links` and
`messages that contain links`.
This commit changes this to a consistent suggestion string.
Fixes: zulip#30908
Previously, when "adjusted_terms_if_moved" was called for non stream
messages, it used to return "null" for adjusted terms. This is true
for some extent since the non stream messages can not be moved.
However, in case of narrow containing "with" operator, this would
be buggy since there, we want the narrow terms to be adjusted
according to the "with" operand to point to the current narrow,
rather than returning null.
This commit updates the method to return null only if the "raw_terms"
dont contain "with" operator. Else, adjust the "raw_terms" according
to the message.
Before this, settings_tab.hbs was being used to test the `{{#tr}}`
syntax for tagging strings for translation. That was introduced in
82b5d9304b, when the template in question
was small enough to mock.
There are smaller templates than `user_notification_settings` but since
none of them are used as a partial in another template, we can't use
them for this test. This is because we can't test partial block
handling part of the tr tag in templates.js with those templates. Since
`user_notification_settings` has only 1 partial, it will atleast make it
easier for us to know which arguments to pass to the template; in
comparison to `settings_template` where it was hard to determine which
arguments were supposed to be passed to the template.
I've also renamed the test to not say `tr_tag` since it confused me with
the HTML <tr> tag when trying to read the test.
Fixes https://github.com/zulip/zulip/pull/30824#discussion_r1677204395
We used to just drop moved messages from the list of messages to
update if we didn't have them cached. So, if the user is in the
narrow where messages were moved to, user will not see the moved
message if they were not cached locally.
To fix this, we re-render the narrow after fetching messages from
the server.
We don't want to use `fast_track_current_msg_list_to_anchor` here
since that function assumes that current rendered state of the
message list is correct which is not the case here.
We've renamed `get_all_preferences` to
`information_section_checkbox_group`. We've also converted it from a
function into a dictionary since it doesn't contain any page_params
variables anymore. This is a preparatory commit for adding a new
`Information section` as part of a layout change for this page.
Adds server and web app support for processing the new `with`
search operator.
Fixes part of #21505.
Co-authored-by: roanster007 <rohan.gudimetla07@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
While using the pill in `stream_create`, it was noticed that deactivated
users were also part of the user_ids returned by the user_group_pill,
which we do not want to do.
This pill is used in two areas: compose box and stream create/edit.
This commit will only affect stream create/edit since compose box was
just using the typeahead data from user_group_pill and nothing else.
Stream and user pill handle inactive users already, so no change is
needed there.
For system groups, the directive is that we should use the description
as the display name. But in case of `role:everyone`, the description is
`Admins, moderators, members and guests`, while for the
`user_group_pill`, we want to display a simpler and succinct message:
`Everyone`. We've only hardcoded this for user_group_pill since we don't
want to display the name as `Everyone` anywhere else yet.
We've also exposed a method called `get_display_group_name` which will
be used in later commits to get the group display name.
While the support to include all members of a subgroup is needed only in
the `stream_create` context for now, we have added the support for
subgroups to `user_group_pill` for all cases. We have done this because
that is still going to be the correct behaviour if we add similar
support to other pill inputs.
In terms of calculating and populating the recursive member list, it was
decided not to do it when initializing the user_groups data. One reason
for that was it would introduce a lot more complexity when adding or
removing members from any of the subgroups to keep the recursive member
list updated. Keeping in line with the general pattern of calculating
recursive subgroups on the fly too, it was decided to calculate the
recursive list of members on the fly too.
Also changes the `get_group_ids` tests to make sure that subgroup ids
are not part of the result of `get_group_ids`. Since it is used to
calculated taken_groups, we don't want to filter out subgroups as part
of taken_groups and their typeahead should still be visible.
This function goes through all subgroups recursively and returns the
resultant set of the members of those subgroups in addition to the
members of our target_group.
This function is required in order to add the `everyone` pill to create
channel flow.
For the tests written in this commit, it uses the same pattern as the
`get_recursive_subgroups` test.
`is_user_in_group` could have been technically refactored to use
`get_recursive_group_members`, but since the former returns early for
direct members, I've let it be for now.
Transforming valid stream/topic urls to the #**stream>topic**
syntax.
- A valid url contains a stream and optionally a topic
but nothing else, and in that order.
It must belong to the same origin as the Zulip server.
The stream id present in the pasted url should
correspond to an actual stream in the current
server.
- `near` links are not transformed.
- Use-mention distinction is respected by
not transforming a valid url if pasted using
`Ctrl+Shift+V`.
- No transformation occurs inside a code block.
- On pressing `Ctrl+Z` after pasting,
the actual pasted link is restored.
- No transformation occurs if the url is pasted over an
existing url in a markdown link syntax.
- No transformation occurs if the stream or topic name
contained in the pasted url is known to produce broken
stream/topic syntax links (as per #30071).
Fixes#29136
To increase the number of options available for the user to pick from,
we increase the limit of options shown to 50 for all typeaheads, and
make the menu scrollable. The max height is set to original height of
the composebox typeahead menu, which fit 8 options or to 95% of the
window height, whichever is smaller.
Fixes: #20620.
Three events i.e. 'stream create', 'subscription add', and
'message' event are received by client on channel creation.
Earlier, we were narrowing to channel while processing the
'stream create' event. This was resulting in fetching messages
for that narrow even before adding subscription. This resulted
in a bug where "You subscribed to" bookend was visible in the
message feed after the "channel events" message.
This commit updates the logic to narrow ONLY after adding
subscription i.e. while processing "subscription add" event.
Note: A channel creator who is not going to subscribe to the
channel themselves is NOT narrowed to the channel view.
This fixes the incorrect behavior.
User circles indicating their presence are now synced across
all the places they appear, except for:
- navbar_personal_menu_popover - since the status
there will never change.
- typeahead_ist_item - because it is short-lived.
Fixes#30536
This commit hides invalid terms, since we don't want to be suggesting
invalid options to the user. We had already hidden invalid has and is
in the past, but this will also hide things like invalid channels or
user suggestions.
In the future it would be helpful to do two followups:
(1) Update the text for invalid is and has in search_description.hbs
since it looks a bit strange (though not introduced here). This
only shows up if you typed an invalid is/has and then start
typing a term beside it, so it's not very likely to happen.
(2) Don't auto-highlight the first typeahead result when there are
no valid suggestions for the last text term. This seems hard
to implement, so I'm leaving that out for now.
This supports adding users to DM pills by simply typing
a user's name in the text input directly after a complete
dm pill. It only works for DM pills at the end of search
input.
Clicking the X button removes a user from its user pill
container, and if that user was the last user left in the
container, then the whole container is also removed.
When the user has selected e.g. "dm:" from the typeahead, we want
to keep this as text, and let them type the search term in full
before it's pill-ified.
Most search suggestions are determined using the "last" search
input term, and the "rest" of the terms. Previously the "last"
term was whatever was at the end of the search query, and we
didn't differentiate between a completed term or an in-progress
term.
Now that there are search pills, we can differentiate between
completed and in-progress search terms, which clarifies some of
the search suggestion logic, and which we'll need to support
group pills and adding users to existing group pills.
There's still a bug when opening the search bar where the input
isn't selected. But I'm not worrying too much about that because
that text is about to be replaced with pills.
Fixes#22113.
The search will only be visible when in the `more conversations`
view. Once we click `back to channels` and close the
`more conversations` view, the search will clear and the search
box will disappear.
We've chosen `pm_list_data.get_conversations` as the function
to which we will pass our search term. We could have technically
found the value of the filter element via JQuery in pm_list_data,
but pm_list_data does not handle any JQuery and we should keep
it that way.
`pm_list_data.get_list_info` also accepts the search_string so that
the info it returns in expanded view is accurate.
We've also added some code to `click_handlers` to make sure that
clicking the search input does not bring us into the DM narrow.
This function does not respect `,` (commas) in the search term and will
treat a comma as any other character. We can decide how to treat comma
separated terms in future iterations. That is also the reason that we
introduce this 2 line function instead of just using the person matcher
directly in future commits. This function still supports search terms
with diacritics because of using person matcher.
In a2ef1d7e93, we made changes so
that when you send a message, your view jumps to the conversation
where you sent it.
For some users it was an improvement, few reported that it
disrupts their workflows.
This prep commit adds a setting which will be used to allow users
to decide whether to automatically go to conversation where they
sent a message.
We clean up unnecessary nesting in this commit and replace one
usage of `#direct-messages-sticky-header` with
`#direct-messages-section-header`. Since `.direct-messages-container`
was being used along with `#direct-messages-sticky-header` at multiple
places, just removing the nesting would break those selectors. For those
selectors, they have been refactored to just look for
`#direct-messages-section-header` instead. `.direct-messages-container`
specific selectors still exist but they apply to both instances of
`.direct-messages-container`, the DM header and the DM list.
When `sort_emojis` function was called from emoji_picker
module, the passed arguments did not contain `reaction_type`
field. As a result the first conditional of `is_popular` function
inside `sort_emojis` always failed -- hence the array
`popular_emoji_matches` was always empty`[]`. This compromised
search especially the order of filtered emojis.
Instead of checking for `reaction_type` === "unicode_emoji" -- we
check `is_realm_emoji` field is false. Since `is_realm_emoji`
field in always present and also results in easier types, this
should be prefered over adding `reaction_type` field to the passed
arguments.
Fixes zulip#30439
Earlier, in left sidebar, clicking on followed topic icon would narrow
to the topic.
This commit introduces the ability to open topic status menu from
left sidebar from followed topic icon.
Fixes: zulip#28941.
Adds `has_conversation` function in
`pm_conversation.RecentDirectMessages` for checking whether we have in
cache evidence of previous messages in a direct message conversation.
Preparation for #28470.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit adds new functions which will be used to discard
changes for all the settings in a subsection when clicking
on discard button. This change will help in avoiding code
duplication when they will be used to discard changes in
a subsection if some other user changed a setting in the
same subsection.