In very large communities, computing page_params can be quite
expensive. Because we've moved the homepage for communities with web
public streams enabled to be the Zulip app, and it's common for
automation to frequently poll the homepage of a Zulip organization,
we'd like to keep those homepages cheap (as the login pages are).
We address this by prototyping something we may end up wanting to do
anyway -- having the web application do a `POST /register` API call in
order to fetch most page_params, and merging those with the mostly
webapp configuration page_params that we leave in the / response for
convenience.
This exact implementation is messy in a few ways:
* We rely on the assumption that ui_init.initialize_everything happens
before all code that needs to inspect the page_params properties we
are fetching via /register. This is likely mostly true, but nothing
in the implementation enforces it.
* The bundle of ~25 keys that are in page_params ideally would be
considered individually, with some moved to the /register API
response and perhaps others eliminated or namespaced inside a
webapp_settings object.
* It's weird to have the spectators network sequence different that
from logged-in users, and potentially a maintainability risk.
* We might be able to arrange that the initial `/` response be
cacheable, now that we're no longer embedding our metadata inside
it. We've made no effort to do that as of yet.
Despite those issues, this commit solves an immediate problem and will
give us helpful experience with a model closer to the one we'll want
in order to happily support a web client that can be run locally
against a production Zulip server's data.
Co-authored-by: Anders Kaseorg <anders@zulip.com>
Previously, we were masking the realm_description raw Markdown with
rendered Markdown, which was a type error.
When we switch to calling /register explicitly in a few commits, this
results in a bug, since the raw Markdown ends up taking priority.
Fix this by just using a different name for this different concept.
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.
This function will replace `settings_ui.do_settings_change` for api
requests which confirms from modals to make loading indicator and
error handling easy and clean inside modals.
Also replacing some previous code blocks of `channel` with this function
in `settings_users.js` which was being used for confirmations modals.
This has the side effect of doing better in-modal error handling for
accessing the user info modal from the "Manage user" button in user
info popovers.
Additionally, we now show a loading indicator while waiting for the
server in these modals.
CZO: #frontend > Error handling inside modals.
The tooltip for the "Announce Stream" hint was not consistent with the
rest of the settings so it has now been replaced with the standard tippy
tooltip. The "?" icon has also been replaced by the "i" icon to match
the other settings.
Fixes: #21312.
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>
This change decreases the time required to open compose
after clicking a message. The amount of time reduced varies with pc.
The time reduction was around 0.4s to 0.6s for me after using a
6x CPU slowdown. This may not sound convincing but the profile
uploaded in #21979 clearly shows the root cause of having a message
click take 10s was the `:visible` query.
Fixes#21979
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.
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.
Previously, these buttons were centered via flex, which meant that in
the rare case that a long list of private message recipients caused
the recipient area to line-wrap, these icons would be incorrectly
placed at the vertical center of the now multi-line block.
Fix this by setting an auto bottom-marging.
Fixes#21693.
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.
The old link here broke once we introduced separate APKs per ABI,
in zulip/zulip-mobile#5296.
We could make a direct link to app-armeabi-v7a-release.apk , the one
that's compatible with almost all devices. But perhaps better is to
just go back to linking to the release page, where the user can
choose the best APK for their device. (If they're in the habit of
downloading APKs manually to install on their device, then probably
that means they're going to be used to choosing the right one.)
User report and discussion:
https://chat.zulip.org/#narrow/stream/48-mobile/topic/Direct.20apk.20download.20link.20is.20404/near/1358758
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.
We only need to loop through the preprocessors
once, and we should use the options passed
in to the parser, not the default options
from the original setOptions call.
The first loop here was doing nothing.
Our sub (i.e stream) and user_group objects have a bunch
of fields that aren't relevant to markdown parsing, so
we create narrow types that make it easier for us to
share code with mobile in the future.
I considered working purely in id space, but the problem
there is that user-entered stream names and user group
names need to be canonicalized.
The abstract_map() helper clarifies that our code
doesn't need a concrete Map object from JS. This
change is possibly premature until we get a little
bit closer on integrating with mobile, since it
solves kinda the same problem that we might handle
more elegantly with TypeScript or Flow.
OTOH I find it to be pretty non-intrusive for the
webapp.
These are the low-hanging-fruit places where we
can avoid using the helpers global.
The long term goal here is to make the markdown
code truly re-entrant, but some challenges still
remain.
Before this change, we would use **some** options relating
to parsing messages, but not all of them. The reason for
this was completely unintentional.
It's mostly a moot point, since the server sends back pretty
generic messages when you do something like invoke the
"/dark" command, and the message would parse the same way
whether or not the parser was looking for things like user
mentions or stream links.
In order to make this code predictable, I had to decide
whether we do a completely vanilla parse or a full message
parse. My decision now is mostly tactical. It's a trivial
one-line change to just use all the options for message
parsing, whereas it requires a major overhaul to allow a
vanilla parse.
I also predict that we will eventually want to parse these
server responses as if they were messages. I doubt the
zcommand responses would ever take advantage of it, but I
could imagine things like nag messages wanting to use user
mentions.
Even if my predictions are wrong, my decisions here are
pretty easy to reverse once we learn more.
For the particular case of zcommands, it is puzzling to me
why the server doesn't just send back HTML, but I don't want
to open that can of worms yet, as that would technically be
an API change.
For now I am happy with the one-line fix.
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.
This is mostly done for correctness reasons--it is
easiest from a logical standpoint to set the realm
emojis at the end of the function, since we do not want
them to be overwritten by normal emojis. The code
worked before this change, but it involved a clunky
check to map.has().
There is also probably a very minor performance
improvement insofar as N (the number of normal
emojis) is typically greater than R (the number
of realm emojis), and we eliminate N calls to
map.has in return for R calls to map.set. Even
if R is quite large, the readability advantages
probably far outweigh any performance considerations,
since we are using native map calls.
Thanks to Austin Riba for this suggestion.
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.
The backend validates that URL inputs are RFC valid URLs (with no
specific length limit), but the frontend appears to have a maximum
length of 50 specified, likely because of a copy-paste error.
Increase the HTML maxlength for this input to 2048, which is a length
supported for URLs by all major browsers.
Fixes#21633
This commit fixes the template of stream deactivation modal
to tag all the text for translation. This commit also removes
the unnecessary span element.
The feature deactivates the bot user; Zulip has no "delete bot"
feature. So fix the label to match what it does.
We also change the icon to match the one we use for deactivating users
in the "Manage users" UI.
For user who is not an administrator.
Also implemented a banner that notifies the user if they can edit
the following settings (name/description and stream permission).
Also increased padding-top of stream header by 10px. This change is done
to increase vertical spacing between the banner
and the stream header.
Fixes#20001.
Fixes#21619
We need to adjust height of recent topics along with the app
otherwise the container becomes separately scrollable due to
it overflowing the app height.
This is definitely better than having linkifiers
reach directly into marked.js, but there is
probably further improvement we can do here
to clean up how these regexes get set.
This introduces a circular dependency between
markdown.js and linkifiers.js, but we will
soon break it in the other direction.
Note we now avoid linkifier checks for the case that a message
contains more obvious backend-only syntax such as attachments.
The next commit will eliminate the ugly early-return.
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.
We were showing the push notifications tooltip in user default
settings section even if the push notifications were configured
on the server.
The bug was because the setting value was undefined in the template
used for user default settings section, so this commit fixes the bug
by correctly passing the setting value to relevant template file.
Fixes#21602.
This is the same sound that since zulip/zulip-mobile#5221 has been
the default notification sound for Zulip on Android.
The actual sound was created by Anders.
Co-authored-by: Anders Kaseorg <anders@zulip.com>
This is especially to add more space around the globe icon since
it wider than lock icon, so the previously set padding for the
stream icon has to be increased.
We use `fadeOut` effect to hide the scroll to bottom button more
widely. We already use `fadeIn` effect to display the button
every time.
We deliberately don't use the `fadeOut` effect when doing
`make_compose_box_full_size` to avoid any button overlap with
compose for a short time.
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.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
This change was motivated by the addition of status emoji to the buddy
list. Previously there was no spacing between the status emoji and the
unread count, and as such, this commit adds a left margin to the
unread count.
The above change has an additional consequence, long user names such
as "Othello, the Moor of Venice" get truncated with ellipses, instead
of reaching to the edge of the unread counts (as they previously
would).
While the 2px value that we had previously chosen looked alright for
most emoji (😀, 😃, etc) some emoji such as 🐙
used more of the width available to them and as such still looked too
close to the user name. As such this commit bumps the value to 3px
(4px was a bit too much space).
Previously, we were experiencing a regression in the positioning of
the play icon for youtube previews, as such, this commit uses a
previously created `handle_video_preview_mouseenter` to ensure the
positioning is always correct.
This is an ugly way of doing things, because this could be handled
directly through CSS flexbox, however, it is an acceptable temporary
fix.
This commit extracts the logic used to ensure that the play icon is
correctly positioned over the video preview for embedded videos, with
the intention that we can use this to fix a regression in the play
icon positioning for youtube video previews.
We render a login button for images that failed to load for
spectators. The image failed to load most likely due to being
rate limited by the server.
Fixes#19840
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.
At the moment we fit only a single image per message per line. This is
wasteful of space as multiple images can be accomodated per line on
widescreen displays. This commit modifies the rendered_markdown
stylesheet to make this possible.
The comments detail various technical considerations.
Fixes#20975.
This revised globe icon avoids looking like a "language choice" icon
(as the previous one did), while still being recognizably Earth (and
not a disk with some things drawn on it) and not showing only North
America (a flaw with the Font Awesome 4.7 icon).
Used a derivative of icon from
https://unpkg.com/ionicons@5.5.2/dist/svg/earth.svg
with modified outline by Vlad Korobov.
There is config_data for the embedded bots only for giphy and
followup bots, so we send "config_data" field to API only for
those bots and not others. Send config_data field as {} to
the API for other bots raised InternalError earlier.
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.
The "download" attribute on the button only functions for same-origin
requests; thus, the download endpoint must be used in order for the
"Download" button to function for uploaded images which are stored in
S3, and thus served from a different origin.
This is only done for uploaded images; it does not address a similar
problem with Camo, when Camo is hosted on a different hostname.
Fixes: #19238.
Previously, the maximum width for the topic input in the compose box
was artificially limited to 20% of the width of the compose box.
While this may have had some useful role in encouraging short topics,
we can teach that idea in other ways, and it seems more helpful to
have the input length match what works well for viewing topics in the
left sidebar without being cut off.
Currently, when deactivating a user, we have a "Saving..." loading
indicator and any error message displayed in the heading area of the
users table.
Migrate this to instead do the loading indicator and error message
inside the modal, where it's more in context.
Improved the contrast of ? and i icons by changing their opacity to a
consistent 0.6, going to 1 on hover.
Changed the colour of playground icon by testing and added spacing
between title and the playground icon by changing the icon margin.
With some TODO comments added by tabbott for readability.
Fixes part of #20484.
Close buttons are misaligned if the warning banner text takes up two lines.
We increase the specificity of the selectors to ensure that this CSS
overrides Bootstrap.
Fixes#20839.
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.
Render tooltip to stream_sorter_toggle buttons using
appendTo method of tippy.js to ensure that tooltip doesn't
get hidden behind the parent container and is visible
completely.
Fixes#21329.
Previously, hovering over the table headers in the code playground
table in the dark theme looked wrong. We were able to trace this issue
to the table-sticky-headers class not having been applied to this
table. The `alert-words` table was also affected and is fixed as well.
This also adds the `actions` class in alert-words table to fix the
inconsistency of the actions column in that table.
We've done an audit and these are the only two instances of either
bug in the HTML templates for a settings table.
This commit adds a tippy tooltip to the lightbox title which enables the
user to view the filename of an image if the filename is different than
the image title.
Fixes: #21333
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.
We check if stream and topic present in the URL match that of
the message in its current state. If message is not available locally,
we fetch it before rendering the narrow.
Fixes#15290.
It turns out that the bug this call hopes to fix only happens when the
user first loads the page to recent_topics and then navigates to a
view with a message list (any other view), but we'd make this call
every time the recent topics table was hidden.
Hence, this commit makes it such that we only make that call if (1)
the page is loaded to recent_topics and (2) we're switching from
recent_topics to a message list view for the first time. We achieve
(1) via binding a handler via ui_init.initialize_everything and (2) by
binding the handler as `.one`, so that it's unbound after its first
invocation.
Additionally, we use window.requestAnimationFrame to prevent this
forcing the browser to do a reflow unnecessarily.
Combined with other commits in this series, this fixes a major
performance problem when leaving recent topics for another view.
See #20255 for details.
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.
The previous logic didn't make sense -- the scroll offset in recent
topics is not a scroll offset within a message list, so saving it was
useless at best.
However, it was actually much worse than that, because trying to save
the pre-narrow offset while in the process of navigating away from
recent topics had the side effect of forcing a reflow, which resulted
in very expensive browser rendering to no purpose.
Adding this commit to the rest of the series of commits fixing
rendering issues when leaving recent topics, this commit results in an
impressive 3.05 s decrease in the first renarrow, an ~ 300 ms decrease
in the second renarrow and an ~ 500 ms decrease in the third renarrow.
There are still further forced reflows which could be reduced in this
render path, but they seem to not be as severe.
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
When a user clicks outside the typeahead menu, inside the typing area,
the cursor position potentially changes, so `lookup` is called, which
considers the new cursor position and accordingly hides, continues
showing, or updates the typeahead menu.
This fixes the bug where even after clicking elsewhere, the old
typeahead menu continued showing and on making a selection, the text
was inserted at the wrong (new) position.
Fixes: #21302.
The upload spinners for all of the image upload widgets were in
wrong alignment due to the use of magic numbers to center them.
This commit replaces the above mentioned approach with the use
of flexbox to fix alignment issues across all the image upload widgets.
Due to differences in length of the words for different languages
there were alignment issues in the organization profile settings.
This commit uses flexbox to ensure that the alignment stays correct
for any changes in language/word length.
Fixes#21385
The ready method was deprecated in jQuery 3.0, because its behavior
has nothing to do with the selector; it always waits for the page to
become ready, not a specific element.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
It was broken by commit f5fbf5f0e0
“change_password: Migrate modal to dialog_widget” (#20193), because
the new_password input didn’t exist when we tried to install an event
handler for it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
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.
Previously, we did not clear the resolved topic warning when reopening
the compose box after sending a emssage. This was a latent bug before
the previous commit, since the resolve topic was always displayed when
the compose box was pointed at a resolved topic before the previous
commit.
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.
Make `compose_control_menu_wrapper` clickable and allow tab focus
on it. Disable tab focus on `compose_control_menu` icon. Fix outline
for `compose_control_menu_wrapper`.
Extend out custom outline property to all `[role="button"]` elements.
The 3 instances of dropdown_list_widget using the `label` property had
different design than the rest of all of our dropdowns, in that the
label was on the same line as the dropdown.
Fix this by adjusting the `label` option to use our standard
`dropdown-title` CSS class.
Also remove the colons in the labels.
I confirmed that these were the only instances of this widget using
the label feature.
Fixes#20415.
The previous icon had a slight asymmetry, some not-quite-straight
lines, and curves with an excessive number of nodes resulting from
some kind of vector → raster → vector workflow. Rebuild it from
scratch. This will be visually equivalent but render more
efficiently.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The most plausible situations through which one would press these
hotkeys with the compose box still open are accidents (basically,
you're trying to type but the browser focus is unexpectedly not in the
compose textarea).
So we disable these keyboard shortcuts when the compose box is open,
regardless of where keyboard focus lies.
Fixes#21128.
Starting composing a message to a new recipient will clear the compose
box. Previously, we were saving drafts before doing so only in the
compose_actions.respond_to_message code path (i.e. when starting a
reply). Logically, this behavior should apply regardless of why we're
initiating a new message, so it belongs in compose_actions.start.
Fixes#21128.
Fixes#21171.
This class was leftover from a very old version of this design, and
had the side effect of settings `overflow: hidden` on the panel.
This, in turn, resulted in the focus outlines for clicking on
checkboxes looking broken.
Previously, these two headers were inconsistent with the rest of the
application, and with "Edit subscribers". We make them the same as
"Edit subscribers".
In "stream_types.hbs"
For "Who can access the stream?" and "Who can post to the stream?" replace
"h4" with "label" to make the for smaller and to remove boldness.
For "Message retention for stream" replace the "h4" with "label"
and add class="stream-title".
In "subscriptions.css":
Add "margin:25px auto" to "#announce-new-stream" to ensure equal
gaps above and below it.
Reduce margin and paddings for ".radio-input-parent".
For "select" set "width: fit-content" and
"height: fit-content" to ensure that the text in the
dropdown is clearly visible.
Fixes: #21322
In stream edit and stream create replace the existing checkbox
format for choosing "stream post policy" with dropdown widget.
In "stream_types.hbs" implement the dropdown menu and remove
the checkbox format for selecting "stream post policy".
In "stream_create.js" and "stream_edit.js" edit the code for
"stream_post_policy" to extract the "stream post policy" value
from the dropdown menu after submitting the form.
In "stream_data.js/stream_post_policy_values", change, the object to match
the following order and description of these policies:
1. Everyone [Default]
2. Admins, moderators and full members
3. Admins and moderators
4. Admins only
This sorts from least to most restrictive.
This commit fixes the issue where the delete (x) button on the
top right corner of the profile picture section remains hidden
even when a hover action is performed on the profile photo.
We loop through edit history entries and see if any of them
are more interesting than a (un)resolve topic edit, extending
the existing loop we had.
We also update the associated node tests.
Fixes#19919.
Co-authored by: Lauryn Menard <lauryn@zulip.com>
Updates the simulated edit history entries that are saved when
`update_messages` events are received for the modern data
structure on the server for `message.edit_history` entries.
Also cleans up a misnamed field in said entries, `edited_by`.
Uses the `rendering_only` field in the `update_message` event
to filter the addition of `last_edit_timestamp` to the message,
which is what triggers the addition of an `Edited` notification
when a message is rerendered in the web app.
Also, removes the deletion of `msg.last_edit_timestr` since this is
regenerated every time the message is rendered, and so it did nothing
beyond confusing the code.
We already show the error if topic input is empty and it is
not allowed to send messages without topic in the organization,
and this commit also shows error when topic is "(no topic)".
The topic is set to "(no topic)" when someone sends a message
with empty topic input box and when it is allowed to send message
without topics in the organization.
This is not ideal behavior as we may want to treat "(no topic)"
differently from empty topic, but we can fix this in future and
this commit can be a short term fix.
Fixes#21344.
We have two different frontend implementations of computing the
un-resolved form of a topic name, and they have a subtle -- but
intentional -- difference in behavior.
Factor them both out into the resolve_topic module, along with
their inverse, and with comments and tests.
These two conditionals are each relying on the other to trigger
on the same condition, and to do complementary things. Move them
together to a single place so that that relationship is easy to see,
and to refactor.
The most notable change here is that when you are adding
subscribers to a stream as part of creating the stream,
you can now use the same essential pill-based UI for
adding users as we do when you edit subscribers for an
existing stream.
We don't try to exactly mimic the edit-stream UI or
implementation, since when you are adding subscribers
during create-stream, we are just updating a list in
memory, whereas in the edit-stream UI, we immediately
send info to the server.
Fixes#20499
The effective date on the DPA should have been February 7, because we
didn't actually update the zulip.com website until that day.
(This commit was added to the internal zulip.com branch during
deployment of the last DPA update, so users always saw the correct
information).
This unfortunately requires somewhat ugly duplicated code, but I think
it's the best option for now.
I expect we will somewhat soon work on the transition to no longer
have two duplicate fetches here, and doing so will let us remove this
secondary code path.
Fixes#21304.
I made the header sections above all our settings
panel lists more consistent.
Before this change:
* some lists had titles, others didn't
* the placement of the filter box was random
* alerts strangely went between the filter box
and the list
* filter boxes were too large
* CSS was haphazard
* forms were squished against tables
Now all the settings with list have consistent
HTML, CSS, and look-and-feel in the area directly above
their list of items.
With the exception of Custom Profile Fields, all the
lists with headers above them happen to be based on
ListWidget, but the header styling is not coupled
to ListWidget, because we want consistent headers
even if Custom Profile Fields has a non-ListWidget
list (due to its drag&drop features).
Previously, this had different hover behavior from the adjacent
elements, which seems like a bug.
The CSS for this component is shared with Recent Topics; we migrate
the styling for on_hover_topic_read for consistency.
Fixes#21273.
Because Zulip Mobile supports some older iOS browser versions that
don't have replaceAll support yet, and mobile is averse to doing the
infrastructure work required to add a, polyfill we avoid using them in
the shared module for now.
See https://caniuse.com/mdn-javascript_builtins_string_replaceall
Prefer a regexp match over using String#replace to strip expected
prefixes and suffixes because (a) it implicitly verifies that the
input has the expected format and (b) it won’t unexpectedly strip from
the middle of the string.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
You generally only need to type a few characters to filter
down to just a few folks, even in gigantic realms.
I tried not to make it **too** small, just in case, but
the default width was kind of gaudy.
Tim Abbott
Anders Kaseorg
yogesh sirsat
Sahil Batra
Ganesh Pawar
Raghav Luthra
Lauryn Menard
Aman Agrawal
Tanya Singh
Dinesh
Somesh Ranjan
Adam Sah
sayamsamal
Greg Price
Greg Price
George A. Michel
Austin Riba
somesh202
aparna-bhatt
Sdrummolo
jai2201
Steve Howell
Archisman Das
NerdyLucifer
Palash
Heidi Ahlberg
Alya Abbott
YashRE42
ditsuke
Alex Vandiver
Rishabh-792
SantamRC
My-Name-Is-Nabil
Biki-das
strifel
Nikhil Maske
N-Shar-ma
Suyash Vardhan Mathur
Lauryn Menard
prashantpaidi
Greg Price
Junchen Liu
