This PR implements literal emoji match in the emoji picker (for reactions)
and in emoji typeaheads (in compose box)
Tested on mobile browser by opening the emoji picker with the
reaction button, selecting an emoji via the native keyboard, and
ensuring the selected emoji appears in the emoji picker’s search
result.
Fixes#21714.
In order to make it possible to search emojis with emoji literals,
we need to make the reaction_type of every emoji available in the
emoji objects used by the composebox.
We directly pass the user group object to get_recursive_subgroups as we
already have the object in the caller. We can add separate function which
will accept id as parameter in the future if required.
This commit adds a new "Role" column for the bot-list table in the
org-settings, and removes the user_id column from the same.
The role of a bot is fetched using the `get_user_type` function inside
bot_info().
This also adds the `sort_role` in the sort_fields which sorts the role
column in the bot-list table.
If an organization does not allow to send private messages, it will
not display the "Send private message" option in the profile popover.
Currently, there are only two options in settings, first is to allow
every type of user to send PMs and the second is to disable send PMs
for everyone, hence I am just checking that the second option is not
selected.
Fixes: #21888
This commit swaps the parameter order in is_direct_member_of
function to have user_id followed by user_group_id since user_id
is a member of user_group_id and not the other way around.
In settings, clicking on deactivate bot button will lead to open
confirmation modal, and displaying all status update notifications
inside this confirmation modal.
This commit is a follow-up of zulip#21490.
Adds `want_advertise_in_communities_directory` to the realm model
to track organizations that give permission to be listed on such
a site / directory on zulip.com.
Adds a checkbox to the organization profile admin for
organizations to give permission to be advertised in the
Zulip communities directory.
Adds a help center article about the Zulip communities directory
and uses a shared intro documentation file to create sections in
the articles on creating an organization profile and moderating
open organizations.
Co-authored-by: Alya Abbott <alya@zulip.com>
We change the generic message copy while we're at it.
Also, show login_to_access modal when a spectator tries to access
a stream that either does not exist is is not web-public.
The changes in the last few commits changed the semantics of the
organization default language to no longer be the primary source of
information for a user's language when creating a new account.
Here, we change the settings UI and /help/ documentation to reflect
this.
This'll be shown only when in a different narrow from what
you're composing to.
Takes care of updating display of the button on moving from
one narrow to another and also on changing inputs. This is
what contributes to majority of js code in this commit.
We are not displaying this for private messages since we do not
have a consistent design for both stream and private compose areas.
See https://chat.zulip.org/#narrow/stream/101-design/topic/narrow.20to.20topic.2Fpms.20when.20composing/near/1318548
Thanks to Vlad Korobov for the icon and for proposing various
designs.
This commit attemts to fix the sorting of wildcard mentions by moving
them below the silent mentions in case of PMs.
It adds a condition in compare_people_for_relevance function to check
for private message type and sorts the wildcard mention below the silent
ones.
It also adds test for sort broadcast mentions and compare_people_for_relevance
function in case of private message types.
Fixes: #21643
Adds a drop-down menu for updating the organization type in the
`organization_profile_admin` page. Implements front end for
this setting to work / update like other organization profile,
notification and permissions settings.
One special note about this dropdown is that the listed options
should change once an organization has successfully set a type
other than 'unspecified' in the database. To accomplish this
the initial settings overlay build checks the realm_org_type
value in the page_params to select the correct options list,
and when the dropdown value is reset, either for update events
or for discarding changes, the page_params value is again used
to check for whether the 'unspecified' value should be present
as an option in the dropdown menu.
Adds basic node test for the `server_events_dispatch`.
Also adds a new help center documentation article for this
organization setting that is linked to in the UI.
Fixes#21692.
This commit also adds 'subgroups' field to the user_group present
in the event sent on creating a user group. We do not allow passing
the subgroups while creating a user group as of this commit, but added
the field in the event object to pass tests.
Instead of setting `disable` attribute to the elements, we make
them look like disabled and remove interactions with them. This
helps us keep the hotkey handling logic for navigation easier
to manage.
Fixes#21279
We already correctly treat spaces equivalent to underscores here.
But we don't do so when we then go on to sort the same results.
(We'll be fixing that shortly.) So it seems worth testing for it
explicitly.
For example, if a user's name is "Simon Peyton Jones", we'll already
match that name on the queries "Pey" or "Peyton", as well as on
"Simon P". We should do so on "Peyton J" or "Peyton Jones", too.
Similarly, if the user is looking for an emoji of a face in the moon
and they start by typing ":moon", we'll show them both 🌝 "moon face"
and 🌚 "new moon face", along with some other moon-related results.
If they go on to make it ":moon " or ":moon f", though -- as one very
naturally would in order to eliminate things like "waxing moon" and
"moon ceremony" -- then we mysteriously eliminate 🌚 "new moon face".
Instead, the query "moon f" should match both 🌚 and 🌝.
Found this while comparing the web/shared implementation with the
mobile implementation of emoji search. The new behavior here
reflects what we already do for emoji search in mobile, both in the
compose box's typeahead and in the add-a-reaction screen. The
existing behavior here seems pretty annoying, so fixing it will be
part of switching on mobile to the shared code (zulip/zulip-mobile#4636)
without regressing the user experience.
The current behavior was introduced, more or less, in 245d65eb9; then
revised in 5edbcb87f to make the logic more clear, and a fix made in
542f4766d, all 2018. The PR thread was #8286, following issue #8279.
The old behavior before those changes was pure substring matching,
plus a trailing space was ignored (which is the part the issue was
about.) None of the discussion touches on this question; as far as I
can tell, the fact that "Peyton J" doesn't match "Simon Peyton Jones",
nor "moon " match "new moon face", was entirely an unintentional
side effect of those changes.
Also delete a comment about what properties are used. The comment
isn't true: `sort_emojis` looks at `emoji_code` as well as
`emoji_name`, when identifying popular emoji.
And in any case, over here in a test isn't the right place for an
interface description like that to live, if it were true -- rather,
it should be next to the code itself. That'd make the information
more discoverable when trying to use the code, and would also
increase the chances of getting updated when things change that
would make it untrue.
(For this specific kind of interface information, of course, better
yet would be to be in machine-checkable form right on the code -- in
other words, to be a type annotation.)
This reverts commit a8fd535955.
This reverts commit 944781e873.
In an attempt to introduce code from mobile into web to match literal
emojis, the author inadvertently introduced a buggy and smelly change.
Probably best to leave the implementation of this in mobile where there
is more context about the shape of the emoji object available. Web
doesn't actually benefit from the additional behavior anyway.
See https://github.com/zulip/zulip/pull/21723#pullrequestreview-937051603
This commits adds an wildcard_mention_array which would contain the
mention tokens according to the message type. In case of PMs, it uses
only "all" and "everyone" mentions.
Fixes part of #21643.
This commit attempts to fix the suggestions typeahead for wildcard
mentions in case of PMs by using a conditional which checks for the
current compose_state and changes the string in parentheses accordingly.
In case of PMs, it uses the "(Notify recipients)" string instead of
"(Notify stream)".
There is no guarantee that the code passed into parse_unicode_emoji_code
is valid unicode. In the case that it is not, it might be better to
return undefined instead of throwing an exception: to represent a
non-parseable code.
For context, mobile currently returns custom emojis as emojis with
string names in their code property, instead of actual unicode.
Change the logic for rendering PM threads in PM section to
be in the same as that of topics view --
In default view, only recent 5 PM threads would be shown
and append the active conversation as the 6th one at last
if not present in those 5.
In PM section with unreads, a maximum of 8 conversations
would be shown and rest of them would be hidden behind
the 'more conversations' li-item, clicking on which takes
to the zoomedIn view of PM section where all the present
PM threads would be visible.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This PR implements checking for a literal emoji match in emoji
typeaheads. In other words, if you paste or type panda face into an
emoji typeahead, panda face should be presented as an option to choose
from.
This behavior is currently present in the mobile app, adding it to
shared will enable both platforms to utilize this logic.
marked.js provides a helpful error message asking for bugs to be
reported upstream, but since we're running a fork, we should redirect
such support requests to us.
We can triage as necessary.
This makes parse() more re-entrant.
This also drives out a change to the linkifiers
test, where I no longer couple the linkifiers
logic to markdown concerns. I probably should have
done this in an earlier commit, but better late
than never. I didn't bother to split out a commit
for the test stuff, since it's just tests and
the commit is still fairly atomic in nature.
It has always been pretty arbitrary what we did inside
of setup() vs. parse(), and we want to avoid unpredictable
results from other platforms neglecting to call setup().
On my machine you can parse a simple message in about
25 microseconds, based on a trial of a million messages
with the content of "**bold**". Whatever portion of
that time is related to setup-related things like
compiling regexes should be negligible from the user's
perspective, since we never run parse() in a loop.
The zcommand code was calling directly into the "marked"
library, which was extremely misleading, since you don't
get a vanilla parse of the markdown due to the fact
that markdown.js calls setOptions at initialize time.
This commit shifts the responsibility to markdown.js
as well as adding a bit of test coverage, but it is
otherwise just a pure code-move refactoring.
The next commit will tweak things further.
The mobile app was never able to use the shared
version of emoji.js, because, among other problems
with our code organization, the emoji.js module
is strongly based on a mutate-the-data paradigm
that doesn't play nice with React. The way
that we mutate data and violate encapsuation
here is something that we would mostly want to fix
without even trying to shared code with mobile, so
subsequent commits will try to extract some pure
functions into a shared module.
This gets us closer to having an API that can
be used my mobile.
The parse() function becomes a subset of
apply_markdown() that is no longer coupled
to the shape of a webapp object, and it can
be supplied with a new helper_config for each
invocation. Mobile will likely call this directly.
The setup() function becomes a subset of
initialize() that allows you to set up the
parser **before** having to build any kind of
message-specific helpers. Mobile will likely
call this directly.
The webapp continues to call these functions,
which are now thin wrappers:
* apply_markdown (wrapping parse)
* initialize (wrapping setup)
Note we still have several other problems to
solve before mobile can use this code, but we
introduce this now so that we can get a head
start on prototyping and unit testing.
Also, this commit does not address the fact
that contains_backend_only_syntax() is still
bound to the webapp config.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
f0c680e9c0 introduced a call to
message_helper.process_new_message without first calling
message_store.set_message_flags on the message.
This resulted in it being possible as a race, when loading the Zulip
app to a stream/topic/near narrow, for a message to have the
`historical` flag be undefined due to not being initialized.
That invalid state, in turn, resulted in the message_list_view code
path for rendering the message feed incorrectly displaying additional
recipient bars around the message.
We could fix this by just calling message_store.set_message_booleans
in this code path. However, this bug exposes the fact that it's very
fragile to expect every code path to call that function before
message_helper.process_new_message.
So we instead fix this by moving message_store.set_message_booleans
inside message_helper.process_new_message.
One call point of concern in this change is maybe_add_narrow_messages,
which could theoretically reintroduce the double set_message_flags
bugs detailed in 9729b1a4ad. However, I
believe that to not be possible, because that call should never
experience a cache miss.
The other existing code paths were already calling
set_message_booleans immediately before
message_helper.process_new_message. They are still changing here, in
that we now do a cache lookup before attempting to call
set_message_booleans. Because the message booleans do not affect the
cache lookup and the local message object is discarded in case of a
cache hit, this should have no functional impact.
Because I found the existing comment at that call site confusing and
almost proposed removing it as pointless, extend the block comment to
explicitly mention that the purpose is refreshing our object.
Fixes#21503.
This eliminates an annoying bundle of complexity that caused the
frontend markdown processor's interface with the rest of Zulip's new
message processing code paths being more similar to that of a new
message from the server.
It also cuts down on code duplication.
The previous message.unread block in insert_local_message was
non-functional. markdown.apply_markdown is overriding what that set by
calling message_store.init_booleans, which happens to set the same
value for the `unread` flag, and then setting individual message
booleans as it finds elements like mentions during rendering.
Improve this situation partially by deleting the message_unread block,
and adding conversion logic to translate what the markdown processor
is doing into message flags.
Then, we can call message_store.set_message_flags just like we do when
processing new messages arriving via the API. This will be helpful
shortly, when we deduplicate the calls to
message_store.set_message_flags.
As noted in the lengthy TODO, this exposes the fact that we should
really rework how the frontend markdown processor returns the
mentioned state to its caller.
On changing bot owner, "delete" event is sent to the previous
owner if previous owner is not an admin. We were ignoring the
"delete" event in webapp previously, but now we update the
bots page in personal settings to delete the bot. Note that
we do not remove the bot from the organization list of bots
currently, since list_widget does not support removing a
row as of now.
In case of previous owner being an admin, the previous owner
receives "update" event and thus the bots list is updated
from that event.
The code for ignoring "delete" event was added in fba2708bbc,
to basically avoid failed lookup for id in the organization
list of bots. I have tested and there cannot be a case of
a failed lookup in the list as per current code for list_widget
module and we are anyways safe after a reload or after closing the
overlay as the list will be updated correctly.
Discussion thread -
https://chat.zulip.org/#narrow/stream/321-settings-system/topic/List.20render.20.2315033Fixes#20856.
As detailed in this conversation:
https://chat.zulip.org/#narrow/stream/137-feedback/topic/recent.20topics.20timestamps/near/1337670
This time format change is not working out as an improvement for at
least some users, myself included.
I think we do want to use some of the refinements attempted here (and
in particular, I'm keeping the new function with its nice test suite),
but I think it's better to revert now and fix forward in a future
release.
See #19775 for added background.
This commit adds a tippy tooltip for inline image previews in messages.
There exists some (reasonable) logic in `static/js/util.js` which
overrides all title attributes for links to user-uploaded content to
ensure they always display "Download <filename>". This doesn't make
sense for inline images specifically because they will be opened in a
ligthbox, so we prevent that.
There is an additional tippy instance created in `static/js/tippyjs.js`
to add tippy tooltips to inline images, which takes advantage of the now
preserved title attribute of the parent link.
Creates a helper function in `message_edit.js` that loops over
a message's edit history to see if a stream and topic pair
existed at some point in the message history.
Exports `util.lower_same` function to use for comparing
edit history topics as lowercase.
Also adds test for new function in `mesage_edit` node tests.
The name for a BigBlueButton meeting is now generated from the stream
name and topic name.
The createTime option is used to have the user redirected to a link
that is only valid for this meeting.
Even if the same link in Zulip is used again, a new createTime
parameter will be created, as the Meeting on the BigBlueButton server
has to be recreated.
Fixes#16498.
Fixes#20509.
Fixes#20804.
This is partially a prep commit to correctly saving/restoring the
position of the blue message select box when using browser
back/forward navigation, and partially a bug fix that ensures that
switching from "all_messages" to "recent_topics" preserves one's
position in "all_messages".
Note that this is with regards to saving the visual position of the
selected message, not about saving "which message was selected".
If the target user is deactivated, `Reactivate this user` will be
shown as one of the options in the small user profile popover, where
`Manage this user` would usually be.
We rename `show_manage_user_option` to `can_manage_user` because now
it will also be used as the common condition for whether the current
user has administrative permission to active or deactivate the target
user.
The implementation closely follows the existing deactivation modal.
Fixes#21428.
chat.zulip.org discussion:
design > reactivate user from user popover
Doing these in a loop may help us figure out whether the
flakes are somehow related to the initial conditions when
we run the test vs. some race that can happen later in the
loop.
I add the console statements mostly to facilitate debugging,
but they appear to actually reduce the problem, as the code
comments indicate.
We have a flake related to verifying that the app
prevents us from creating stream with duplicate names,
and my hypothesis is that it has to do with us not
waiting for the stream creation UI to fully appear. This flake
is probably a consequence of us recently making the stream
creation UI more like the stream editing UI, and thus
waiting for Desdemona to appear was giving us false
confidence that the page actually loaded.
I could be completely wrong about this solving the
flake, but the code change here is sensible regardless.
We now use narrow_state directly in pm_list and pm_list_data
tests, rather than mocking it with our `override*` helpers.
In some places I use an actual Filter() object, but
in places where the only testing concern is that the
active is narrow, I use a stub value.
We will continue to mock narrow_state in most places.
In addition to avoiding test-setup complications, we want
to avoid incidental line coverage on narrow_state that
only indirectly validates its behavior. Part of the
trickiness in avoiding narrow_state mocking is that
you often would have to introduce "real" Filter objects,
and the API for Filter objects is somewhat less than
ideal, and its wordiness can distract from the main
point of the tests.
Hopefully the changes here reflect the correct tradeoffs.
Co-authored-by: Steve Howell <showell@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This commit adds the backend functionality to
mark messages as unread through update_message_flags
with `unread` flag and `remove` operation.
We also manage incoming events in the webapp.
Tweaked by tabbott to simplify the implementation and add an API
feature level update to the documentation.
This commit was originally drafted by showell, and showell
also finalized the changes. Many thanks to Suyash here for
the main work here, which was to get all the tests and
documentation work moving forward.
The resolve topic warning can feel like clutter in the event that the
compose box is empty (which often occurs when the user has no intent
to send a message), so we configure the validation logic to only
display the notice when the compose box is non-empty.
We take some care to minimize work the function is doing, beacuse it
is called on every keystroke in the compose box.
Fixes: #21155.
Use proper variable names such as `alice.user_id` for assigning
userId as a parameter instead of directly using a number `101`
and avoid using a variable name `timestamp` for assigning message_ids
to function `pm_conversations.recent.insert()`
Lani
Sahil Batra
somesh202
yogesh sirsat
Ganesh Pawar
Lauryn Menard
Anders Kaseorg
Aman Agrawal
Tim Abbott
Dinesh
Somesh Ranjan
Greg Price
Austin Riba
jai2201
Steve Howell
strifel
YashRE42
Suyash Vardhan Mathur