The previous "Join the {realm_name} community" was awkward for
organizations that put "community" in their realm name, e.g. "Join the
Zulip development community community".
Hiding these UI widgets causing layout issues -- specifically, the
position of the \vdots menu looks off with these elements missing.
Enabling this buttons (and opening the login_to_access modal on click)
provides a light advertisement for these features, seems to be the
standard practice for forum-like software, and will also be easier to
maintain.
This effectively reverts f26a76a9d8, in
addition to adding new logic.
After playing with several options, it feels cleanest to just have the
closed-compose area look exactly how it would if you were logged in;
popping up the login_to_access modal when clicking those buttons feels
reasonable. The extra button felt buggy, and this customization helps
make the Zulip layout more consistent for spectators.
This effectively reverts 5ffc95f6bb.
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.
Previously, clicking MOVED/EDITED buttons on a message would pop up
the message edit history modal, which would (after a brief loading
indicator) get a 400 error for the server and then pop the
login_to_access modal on top of the error in that modal.
Fix this with an explicit login_to_access check. This feels like the
cleanest way to avoid churning the UI (hover behaviors, etc.) as would
be required to make this not clickable.
Fixes#21963.
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.
Runs when there's a change in recipient fields of compose box.
Moved the `update_fade` function to this.
This is a preparatory commit to add a feature to go to the
narrow you're composing to where we want to update the
button visibility when the recipients changes. The update could be
run in the function this commit adds.
There are two tangled issues addressed here:
* We were weirdly using a scaled up copy of fa-angle-up, rather than
fa-chevron-up, for a chevron up, for the expand/collapse widget.
* We were previously using × for the close icon, which had
visual and scaling issues next to the fa-angle icon.
Fixes#20403.
The commit fixes the issue in which the settings sidebar would
overflow into the settings header when scrolled; it also adds
border-box model to minimize calculations and magic numbers.
This changes recent topics to be consistent with our other tables. The
valus are copied from the common settings CSS for tables.
Ideally, we'd just share the CSS, but the existing table CSS is deep
inside a .settings-section CSS block, and it's a bit of a refactor to
share it.
Fixes: #21140.
This change is motivated by a few considerations:
* The message actions menu has grown quite a bit and is at risk of
feeling cluttered, especially with the upcoming Read Receipts feature.
* Conceptually, this menu is for interactions with the message, not
its topic. There are other convenient ways to do this, in the topic
recipient bar and left sidebar; hopefully removing this isn't much of
an inconvenience. (If we add something back, we'd probably want a
full "Topic actions" popover, not just this single item)
* Combined with the next commit, this removes the last copy of the
topic name in this popover, which is helpful to its shape/layout,
since topic names have much more variable length than the labels
present here.
Fixes#21432
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
This makes this function easier to reason about, by having only one
version of the query floating around.
The change is nearly NFC: the one other place this `query` parameter
is used is the `triage` function, and that already lower-cases the
query too.
But `triage` has some additional case-related behavior: among prefix
matches (but not among exact matches), it moves any that match
case-sensitively ahead of any that don't.
As long as all emoji names are lowercase -- as all our built-in
emoji are, and as all custom emoji probably are in most realms --
that still has no effect: either the query is lowercase too and all
matches are case-sensitive matches, or it isn't and none of them are.
But it can show up if someone adds a custom emoji like `:GitHub:`
or `:LaTeX:` (like we have a `` in chat.zulip.org), and then
someone does the natural thing of searching for them in lowercase.
When the behavior does show up, it seems like it can only come
across to the user as a glitch: the emoji that have capital letters
get weirdly taken out of order and moved to the end, or just don't
show up if there are more than 8 results.
In general I'm not convinced there are any situations at all where
this behavior of `triage` makes sense: basically every other
search UI in the computing universe is case-insensitive except for
some aimed at programmers searching through code, and none of our
typeahead searches are aimed at doing that. But for the moment,
just simplify the emoji case in particular.
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.
A bot is technically a special case of a user, in terms of how they're
stored in the database at least, but for end users, we avoid referring
to them that way.
This commit changes the invite API to accept invitation
expiration time in minutes since we are going to add a
custom option in further commits which would allow a user
to set expiration time in minutes, hours and weeks as well.
Added a setting to the bottom of Settings > Display settings > Theme section
to display the reacting users on a message when numnber of reactions are
small.
This is a preparatory commit for #20980.
Previously, the confirm button would be disabled when the user
attempted to change the capitalization of a topic, but still keep
it in the same stream. This commit fixes this discrepancy.
This commit changes the behavior of the move topic modal in
'stream_popover.js'. Instead of relying on an error banner, it
will now disable the submit button whenever an identically named
topic exists in the currently selected stream. To accomplish this,
it introduces a callback, update_submit_button_disabled_state(),
and calls it in three cases:
1. When the modal is initially loaded.
2. When the dropdown is changed.
3. When the topic name is changed.
The case insensitivity of topic comparison has been preserved.
Fixes#21711.
This commit solves the bug which keeps the announce stream checkbox checked
for non-admin users when users are only allowed to create private streams
and not public streams.
The desired behavior is to not allow users to announce private streams, so
we keep the checkbox unchecked and disabled.
This commit fixes the above mentioned bug by removing the if-else block which
was executed after update_announce_stream_state (the function which handles
updating the checkbox considering if the realm has notifications stream or
not and whether the stream being created is public or private) and only checks
whether the realm has notification stream or not to show or hide the announce
stream checkbox irrespective of privacy of the stream being created.
This commit also fixes the handler to update the checkbox state on changing
privacy to update the checkbox state only on changing privacy value and not
on toggling the checkbox itself or changing post policy.
Fixes#21705.
Aman Agrawal
Tim Abbott
Tanya Singh
Dinesh
Somesh Ranjan
Anders Kaseorg
Lauryn Menard
Adam Sah
sayamsamal
yogesh sirsat
Greg Price
Greg Price
Sahil Batra
Raghav Luthra
George A. Michel
