Uptil now only space was used as a word separating character when
searching streams. This meant that searching for "xyz" would not turn
up a stream named "stream-xyz" as one would expect.
Since -, _ and / are likely to be used as word separators in stream
names, these 3 are added as word separators for streams. The utility
function `filter_by_word_prefix_match` is refactored by adding an
optional `word_separator_regex` argument.
Fixes: #19700.
We also show upgrade banner along with disabling the setting.
We also hide the web-public stream creation policy dropdown in
such case as we do when enable_spectator_access is False.
Since we updated the bot edit form opened from "Personal"settings
section to be same as that opened from organization settings
section, we do not require this file anymore.
Fixes: #22033.
We now allow admins to edit configuration of outgoing webhook
and embedded bots from the edit form in "Organization" settings
section. In next commit we would deduplicate the code to use same
modal in both "Organization" and "Personal" settings sections.
This commit adds option to change bot avatar from the admin bot-edit
form. This is a prep commit for making bot edit forms in both
"Personal" and "Organization" settings sections same.
We do not use dialog_widget.submit_api_request now since we need
to pass processData and a couple of other parameters with the
request since we are sending a file also as part of data. And
also we add code to show loading spinner which was previously
handled by submit_api_request.
We now show confirmation modal when deactivating bot from
personal settings section. Since we have added deactivate
option in the bot-edit modal opened from admin settins page
and we would replace the modal opened from personal settings
with that modal, it would be good to show the modal consistently.
This commit also moves confirm_bot_deactivation function from
settings_users.js to settings_bots.js to avoid cyclic dependencies.
We move show_edit_bot_info_modal function to settings_bots.js
as this code will be used for modals opened from the personal
bot settings section as well when we would make both the modals
same and this will help us in avoiding cyclic imports.
The "for" attribute of label of full-name input in
admin_human_form.hbs was set to "full_name" which is already the
ID of full name input in profile section and not the input in
this form.
As a result, the modal was being closed on clicking on that
label. This commit for now just updates the "for" attribute
for full-name input to the correct ID.
The "for" attribute of label of full-name input in
edit_bot_form.hbs was set to "full_name" which is already the
ID of full name input in profile section and not the input in
this form.
As a result, the modal was being closed on clicking on that
label. This commit for now just updates the "for" attribute
for full-name input to the correct ID.
Now that we can assume Python 3.6+, we can use the
email.headerregistry module to replace hacky manual email address
parsing.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This fix excludes the bots and invitation settings tabs from having the
organization_settings_tip.hbs template being inserted in them.
Arguably we should invert the meaning of this block so the default is
that these notices don't appear, but it's hard to be sure whether we're more
likely to add a new setting panel that is normal settings or a data table.
Fixes: #19967.
Fixes some in-app and documentation references to to new user
announcements and new stream announcements that were still using
'notifications' to refer them. These were missed in the original
pass for updating this language.
Change submit button text of both bot and user deactivation confirm
modal from "Confirm" to "Deactivate".
Calling `launch()` function from `dialog_widget.js` because
`confirm_dialog.js` set submit button text to "Confirm".
We currently show stream emails for subscribed and unsubscribed
streams in stream settings overlay and don't show them for never
subscribed streams.
There is a bug where we show the empty container without email on
live update after unsubscribing and then we completely hide the
email element after we switch the stream and come back to it
again. But then we again show emails for unsubscribed streams
after reload, to preserve the beahviour of showing the emails of
unsubscribed streams.
This commit fixes this bug by not hiding stream email on live
update after unsubscribing and also showing them after switching
between different streams and makes it consistent with showing
emails for unsubscribed streams.
Fixes#22308.
We add topic auto-complete to the left sidebar menu as sometimes user
may want to merge the topic they are moving with an existing topic.
With a tweak by tabbott to remove a now incorrect comment.
Fixes#19876.
Providing additional information like number of invites and number of
bots owned by deactivating user in the confirm_deactivate_user modal
will help the administrator if they need to do any follow-up work.
Fixes#20973.
Completed-by: Ganesh Pawar <pawarg256@gmail.com>
We mention about sponsorship in upgrade banner to non-business
organizations. The message for business organizations is same
as before.
There is no explicit hover behavior for banners for org types
other than business, as banners are not themselves links in
such cases and only parts of text inside the banner are links.
Fixes#22161.
Originally, DEFAULT_NOTIFICATION_STREAM_NAME was set to
"announce" and we also showed warning in frontend when
user was composing message to "announce" stream and if
the stream had more than 60 subscribers.
But we changed DEFAULT_NOTIFICATION_STREAM_NAME to "general"
in d46b125bf2. That commit did not remove the frontend code
for showing warning and this commit removes it since there
is no "announce" stream by default now, and we would not
want to show warning when sending to "general" since that
stream could be used for many discussions and it would not
be nice experience to show warning everytime.
We do not show different error messages for different values of post
policy values if user is not allowed to post making it consistent with
other settings like wildcard mention settings and organization settings.
This also helps us deduplicate some code as we use almost same code
for excluding the streams to which user is not allowed to post from
the dropdown in moving messages UI.
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.
Fixes part of: #22482
After moving to settings_checkbox in Authentication Methods UI,
mentions of "table" in the related JS variable/function names
are no longer meaningful and may be confusing. Change them to "list".
On registration and login pages on self-hosted Zulip servers,
it is not helpful and confusing to show the full navigation footer
for the Zulip website. Instead, we should show a minimal footer.
Fixes#21776
When some value is very long as in the case of a long email address,
the text used to flow and hide under the profile avatar. We want the
values to be seen at all times, even if they need to be broken into
multiple lines.
The user status appears out of place among the profile fields and thus
placing it under the avatar avoids any discontinuity between the profile
fields. This also adds the status icon beside the user status.
The placement of the avatar on the right makes the full profile modal
UI consistent with Settings > Profile UI. This also helps the custom
profile fields appear more in line with the default profile fields.
Fixes#21805
This makes the Full Profile layout consistent with the Manage User
layout. Also, since both email id and user id are used to identify a
user, they should be placed together.
The <kbd> elements in `static.templates.keyboard_shortcuts.hbs`
that are arrow keys have a class of "arrow-key". This adds that
class to arrow keys that are updated via `adjust_mac_shortcuts`.
Follow-up task due to changes introduced in #22330.
Updates header "Notifications" to "Automated messages and emails".
Updates these subheaders in that section:
- "New stream notifications" to "New stream announcements"
- "New user notifications" to "New user announcements"
- "Notifications language" to "Language for automated messages
and invitation emails".
Co-authored by: Lauryn Menard <lauryn@zulip.com>
We have observed infrequent storms of accesses (tens of thousands of
requests to minute) to `/` after an event queue expires. The current
best theory is that the act of reloading the page itself triggers a
focus event, which itself triggers a reload before the prior one had
had time to do anything but send the network request.
Since the `focus` event here is merely as a backstop in case the
synchronous reloading and deferred reloading fail, we need only run it
once.
Prevent a non-immediate reload from being scheduled while an immediate
reload is already in progress. This is highly unlikely in practice,
but is a reasonable safeguard.
A `reload.initiate({immediate: true, ...})` *should* not return, as it
should trigger a `window.location.reload` and stop execution.
In the event that it continues execution and returns (for instance,
due to being in the background and reloads being suppressed for
power-saving -- see #6821), there is no need to fall through and
potentially schedule a 90-second-later retry.
We show a confirmation modal when deleting option of a select-type
field mentioning number of users who are using that option. We also
show the modal if no user has selected that option. We show the modal
only in edit-form and not while creating a new profile field. We do
not show the modal when removing a newly added option during editing
the field.
Fixes#22145.
Previously, the value for an option of the select type custom
profile field was set as "order - 1". This commit changes it
to remain same even when we reorder the options or delete an
option. When we add a new option, its value is set as 1 more
than largest value already used.
This helps is eliminating various bugs in this subsystem, where
user's choice is changed unexpectedly when reordering or deleting
options.
Discussion -
https://chat.zulip.org/#narrow/stream/378-api-design/topic/custom.20profile.20fields.20option.20deletion.
This immediately shows the menu for which messages to move when the
user can edit the stream/topic of a message, but not the content of
the message. This balances the concern that this menu might feel like
clutter when doing a content edit with the fact that most of the time
when one visits this menu without content edit permissions, one will
want to be reassured that one can choose which messages to move.
Fixes#19196.
This commit removes role field from StreamSubscription
type and also removes SubscriptionRole type since we are
not moving forward with stream administrator concept and
instead working on new permssions model as per #19525.
This commit removes the stream-admins option for wildcard mention policy
in webapp since we are not moving forward with stream administrator
concept and instead working on new permssions model as per #19525. There
is no functional change, we only remove the by_stream_admins_only key and
instead use by_admins_only with the correct code value.
We declare bot type variables globally in the module rather than in
set_up function as we would extract a new function in further commit
that will use these.
This commit renames get_bot_owner_widget_and_set_role_values to
edit_bot_post_render, since we will modify the function to do
a couple of more things in further commits and this would be
an appropriate name rather than mentioning all the things in
the name.
We rename the file because in further commits we will use
the same modal for the bot edit form in Personal settings
section and that can be done by bot-owners who are not
admins.
This commit removes the redundant code to update the
"src" attribute of bot avatar on changing avatar added
in f7ca0117e6.
We do not need to add version to the url since the backend
already sends url with latest version number and also we
already re-render the bots page after recieving realm_bot/update
event.
This is a prep commit for enabling a two section layout in the
buddy_list. The sections will be for "users" and "others".
Hence, this commit performs a simple rename of:
- `user_presence_row.hbs` -> `presence_row.hbs`
- `user_presence_rows.hbs` -> `presence_rows.hbs`
And then a search and replace of `user_presence_row` to
`presence_row` (which also handles the second rename).
It also makes one modification in buddy_list.js where it changes a
template variable we're passing from "users" to "row_members".
This is a prep commit for adding a two section layout to the
buddy_list. It frees the "other_key" name which we intent to use
extensively in future commits.
We are abandoning jQuery animation because it build up queue
when there is continous switch in animation state.
i.e When user goes ↑↓↑↓↑↓… at the bottom.
Also added `aria-hidden` to `#scroll-to-bottom-button-container` so
that this widget doesn't interfere with screen readers.
Removes the `mac-cmd-style` CSS rule that was introduced in
d3e8348 when support for updating keyboard shortcuts with
the `Ctrl` key to the Mac cmd key, `⌘`, was added.
Removing the rule makes the font-size and font-family CSS more
consistent with other keyboard shortcuts in the documentation.
Also, removes the parameter in `adjust_mac_shortcuts` that added
the CSS class / rule to these specific keyboard shortcuts.
This click handler reset the stream creation form; it's not clear why
that behavior would be useful, or why we'd want anything to happen
when clicking in these background areas, so the correct thing to do is
just remove the handler.
Fixes: #21785
Uptil now, both names and descriptions of streams and user groups were
matched to show the typeahead suggestions. This led to unexpected
behaviour like for a clear mention of a certain stream, the typeahead
menu suggested a completely different stream which had a mention of
the first stream in it's description.
To prevent such bugs and also since description matching is not really
useful for streams and user groups, only names will be matched.
Updates the `adjusts_mac_shortcuts` function to render shortcuts
with the `Fn` key as a separate html element (e.g. `Fn` + `arrow`)
instead of rendering the shortcut as one block (e.g. `Fn + arrow`).
Also, because keyboard shortcuts should be rendered with each key
as a separate html element, updates `adjusts_mac_shortcuts` to
only change html elements that are an exact match to a keyboard
key. Html elements with whitespace will be ignored (e.g. `Enter`
becomes `Return`, but `Enter or Backspace` is not changed though
it previously would have been changed to `Return or Delete`).
Fixes#22112 (in combination with #22273).
New shared `table-striped` CSS class, adds top and bottom side border
already, so adding only left and right side borders to subscribers table
head to avoid weird looking borders.
Making `table-striped` CSS block as a top level shared CSS inside
`app_components.css`, trying to make use of this block on every
table and also removing some dublicated CSS.
Follow-up of #21144
Removes CSS rule that added a left margin and padding to not
first-child paragraph elements and `codehilite` class div elements
in ordered list elements.
Rule was added in 2017 and likely was correcting the alignment of
these elements due to another CSS rule that has since been removed.
We make the tooltips of the button in the top row consistent.
This includes -
* Removing the bold formatting from the "Go to conversation" tooltip.
* Converting the "Expand compose" tooltip to Tippy.
Fixes#22132
After some discussion with the community, we've concluded that in most
cases, one probably wants to notify only the destination thread, not
the source location; so let's make that the default.
We preserve the model that we remember what you did during the last
move in a given browser session, which is very helpful if you're doing
an operation N times in a row.
Fixes#21838.
Follow-up to commit bbda7a5bb0.
The "Announce stream" hint tooltip earlier read "Organization
administrators can change this in in the organization settings."
It wasn't obvious that "this" refers to the stream the notification
will go to, so the tootltip message has been modified to reflect this.
This commit adds a function to disable the subscribers tab for private
streams if a user is not subscribed to the stream and is not an admin.
We also live update the state of subscribers tab on changing privacy
of stream.
Fixes#20916.
Co-authored-by: Sahil Batra <sahil@zulip.com>
This button was red, which is appropriate when modifying an existing stream,
since that's a potentially disruptive action, but not appropriate in the context
of previewing subscribers for a new stream being created.
Fixes: #21863.
The images themselves had been deleted by commit
cc33b68d73, and were then zanitized out
of the commit history.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The PR changes the following behaviors and UI:
1. Removes the checkmark button to mark the topic as read in
"Recent Topics".
2. Make the unread messages counter be the button for marking
all messages in the topic as read. The unread messages counter
is made clickable and tooltip is set to "Mark as read".
In "recent_topic_row.hbs", remove the checkmark button and add
classes and attributes to ".unread_counter" to give it desirable
behaviour on clicking.
In "zulip.css" set "opacity: 0.7" for ".on_hover_topic_read".
In "recent_topics.css" we set the background-color of unread counter to
hsl(105, 2%, 50%) to decrease fading of unread counter.
Fixes: #21654
Previously, when there were no unread messages in a topic, the topic
name was allowed to expand into the space allocated to the unread
count. This matched the behavior of the left sidebar. However, the
left sidebar has extremely limited horizontal space, and being able to
display a few extra characters is useful; recent topics does not have
this constraint. Further, recent topics wraps long topic names on
overflow, which looks ugly when using use the unread count's space.
So we switch to having the unread count element consume space even
when there is no count, using `visiblity:hidden`.
Fixes a part of #19449
Set the default_language as cookie and reload the page so that
the spectator can immediately see the language change in effect.
We can reload the page forcefully for spectators since there is
no chance of any work being lost. It is possible that the spectator
may lose the selected message on doing so.
This requires a new dependency, to be able to set cookies from
frontend JavaScript.
Fixes#21961
It’d be nicer to use hash_util.build_login_link which also remembers
the current hash, but that doesn’t help when the gear menu is only
rendered once at page load time.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
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.
Changes the admin UI for the communities directory checkbox to use
the `realm_push_notifications_enabled` page param instead of the
`server_web_public_streams_enabled` page param.
Updates help center documentation about the communities directory
to have clearer information about how the setting works for
self-hosted communitites.
This commit changes the error message, shown while trying to deactivate
a non existent stream from stream settings UI, from "Invalid stream id"
to "Invalid stream ID".
This fixes the bug where spectators can have filters selected
in recent topics if a logged in user has selected filters in the
same browser.
Log in, select a filter and log out to reproduce this.
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 attempts to refactor the `handle_bot_form` by adding new
field for `Role` in the `Manage bot` modal.
It uses the `/json/users/` url for passing the role of a bot and allow
changing it as in case of a normal user.
Fixes: #21105
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.
New function `hide_all_user_info_popovers` closes all user info
popovers, instead of calling multiple functions everytime to close
user info popover now we can just call this new function.
This commit is a follow-up of #21460.
We add `padding-right` to input field so that input do not overlap with
`x`and add `text-overflow: ellipsis` to make overflow less jarring.
Fixes#19765
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.
The header was more confusing than helpful, and we
want the create-stream UI to be less cluttered.
We don't really need the help-center text here, since
we already have ? icons next to the relevant headings
for the sub-sections.
We kill off some CSS, but we won't kill off stream-title
until the big upcoming changes for stream pills.
Muted streams are now greyed out in the personal settings,
also changes to the notification settings of a muted stream are
not possible anymore.
Also, add a bell-slash icon after the stream name of muted streams,
clicking on it unmutes the stream.
Fixes#19780.
Previously, updating the UI when streams are muted was split between
two places: The server_events.js code path, which updated the checkbox
state and other parts of the app, and checkbox click handler, which
toggled the disabling of the notification settings checkboxes.
Move these to all live in a single place.
With the recent changes to lightbox image handling in #21145 and #20788
it is no longer necessary to have panning and zooming disabled by
default. This commit removes the enable/disable button and instead
replaces it with a "Reset Image" button, and enables panning and zooming
as the default state of the lightbox.
This commit attempts to prevent images with long filenames,
descriptions, or author names displayed in the lightbox from altering
the layout of the page.
It also adds a title prop to both the filename and author, allowing a
user to hover and see a tooltip of the full text in the case where the
text is truncated.
Fixes#21058.
Make the unread marker lines at the side of messages continuous by
adding "height: 100%" to ".unread-marker".
This provides a nicer visual experience by not highlighting the
boundaries between messages. (One can see that information using the
timestamps or by moving the selection cursor, where appropriate).
Fixes#20981.
Hides 'disable' button of any kind when nothing is selected
in dropdown list widgets by removing ':enabled' selector from
the button, the button is not actually a button, it's an <a> tag which
doesn't support "disabled" attribute.
Fixes part of #20831.
We use Label as the heading for the field label column in the custom profile
fields table; but for some reason the edit UI called this "Name" instead.
Fixes#21260.
It's 2022 and the WHATWG no longer recognizes the term URI. Everything
is now a URL or a type of URL. Which is great because it's way less
confusing. Details here:
https://url.spec.whatwg.org/
Moves hash_util.by_stream_uri and hash_util.by_stream_topic_uri to
internal_url so they can be used by external codebases. Due to these
functions being called in many places in the web codebase, wrappers
for both functions are left in hash_util in order to keep these
calls simple.
Also adds test for explicitly testing each function.
Move hash_util.encode_stream_id to internal_url, so it can be shared
with external codebases. Also add a test that explicitly tests escaping
special characters in stream names.
Move stream_data.id_to_slug to internal_url, making it shareable. The
function has been renamed to stream_id_to_slug to reflect that it
operates on a stream id.
Moves the encodeHashComponent and decodeHashComponent functions out of
hash_util and into internal_url which belongs to shared. This is to
accommodate sharing of this code with mobile or any other codebases that
do not wish to duplicate logic.
In order to accommodate the sharing of hash_util with other codebases
including mobile, UI and web specific code should be removed. In this
commit, we remove exception handling for the decodeHashComponent
function and instead add the UI handling of it further up the call
stack.
The stream_data.id_to_slug and stream_data.name_to_slug
functions mistakenly used Javascript's String.replace method,
this commit changes it to use String.replaceAll, the result
being slugs generated from streams with names greater than
2 words are now properly formatted.
An attacker could maliciously craft a full name for their account and
send messages to a topic with several participants; a victim who then
opens an overflow tooltip including this full name on the recent
topics page could trigger execution of JavaScript code controlled by
the attacker.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Inherit uses the settings of the parent element; we actually want to
just undo the `display: none` we'd set for this CSS property, which is
what revert is for.
The previous `display: unset` logic didn't work with dividers in the
gear menu. This new version should be correct -- what we want to do
here is just override the `display: none` default for this class, not
revert to the default browser styling for that element type.
In open_edit_form, we had an initialization order bug where we called
set_up_external_account_field_edit_form, which clears the field name
field if the external account is of the "custom" type, after
populating the initial values for edit form.
This resulted in these fields being displayed as empty in the UI for
this field type. Fix the issue by reordering the initialization.
Fixes: #21262.
This reverts commit f3964673e7.
It broke drafts_scroll by confusing jQuery object APIs with DOM
element APIs.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This should increase its visual priority in the UI. We plan to move
"Private messages" to a different component more similar to STREAMS
soon.
Fixes#20869.
This commit removes the unnecessary `data-list-widget` attribute
present in the <div> and <tbody> tag for muted_topics and muted_users table.
It became unnecessary/useless in 19cf6d0e04 and
then was renamed while still useless.
Also uses the correct variable name `muted_topic` and `muted_user`
instead of `muted_topics` and `muted_users` to render a item of their list
in DOM through Listwidget.
This changes the method of rendering list of alert words in DOM,
earlier it was rendered using 'for' loop over the array of alert_words
which is now changed to render using ListWidget, which gets a array
of objects from get_word_list() in alert_words.js.
The use of ListWidget helps to define a parent_container and $container
in table-body of alert-words-table using which we can now apply sorting over
alert words with the help of handle_sort() function in list_widget.js
Changed the method of adding alert_word_settings_item row in table body
through {{#with}} loop because of rendering through ListWidget, which was done
earlier using for loop over each alert-word in while rendering the list.
this commit also mocks template of render_alert_word_item
while mocking ListWidget.create() function in render_alert_words_ui().
and checks that ListWidget.create() is not called when variable `loaded`
is set as false.
Fixes#21142.
We follow how other apps present older messages, e.g. Gmail,
Facebook Messenger, etc. display it.
Specifically, the logic we use is:
If the time is <24hr ago, show an absolute time, like "21:30" (or "9:30pm").
Otherwise, show what day it was, and not a time
If the day was yesterday, say "Yesterday".
Otherwise, if it was <7 days ago, say the day of week, like "Friday".
Otherwise, if it was <1 year ago, say the month and day, like "Sep 6".
Otherwise, say the year, month, and day, like "Sep 9, 2020".
With some tweaks from Tim Abbott to better handle the future case.
Fixes#19775
Previously, update_user_data was called when deactivating
bots, but it was removed in 58b612a4f0.
Now, update_user_data is only called for 'type="realm", op="update"'
events, but these events are not sent when deactivating or
reactivating a user or bot, so this code is not used.
This commit changes the code to call update_view_on_deactivate function
from server_events_dispatch.js on receiving the user/bot remove event
instead of having it repeatedly in the success_continuation method
of click handlers.
We also add check to make sure we return early if the relevant settings
page is not opened yet.
This commit adds a width of 10px to fa-square and fa-check-square
icons in recent-topics table, so that on toggling between these icons
we can prevent the change in width of the whole button to make it look
good visually.
This commit adds option to deactivate user to "Manage user" modal.
A modal is opened on clicking the option to confirm the deactivation
and the "Manage user" modal is closed.
The error from the server, if any, is shown in the modal itself
and in case deactivation is done successfully, the modal is closed.
Fixes#18944.
We pass handle_confirm function as an argument to confirm_deactivation
because we will use confirm_deactivation to deactivate the user from
user-info popover and the popover case will have a different handle_confirm
function (which is called after clicking "Confirm" button of the modal)
since error handling in that case will be different as there will be no
overlay in the background.
This commit adds a method to detect whether the draggable element has
moved out of view and if it has, move it back into view.
The panzoom library does have a `bounds` option that is supposed to
provide the functionality, but at the time of the commit it does not
appear to work correctly. Upstream bug:
https://github.com/anvaka/panzoom/issues/112
This PR changes the library used for panning and zooming in the lightbox
module from timmywil/panzoom to avanka/panzoom.
The original (timmywil) version of the library contains a bug where if
you have a high resolution touchpad and Firefox and you zoom in and out
repeatedly on an image, the image may drift. avanka/panzoom does not
appear to display this behavior.
Restores the behaviour from before 5f83bc5cfe, where clicking
outside the image closes the lightbox, primarily by way of swapping
out the panzoom library.
Fixes: #21163.
We are going to move to this code organization for
managing streams:
stream_create.js
stream_create_subscribers.js
stream_edit.js
stream_edit_subscribers.js
The modules stream_create.js and stream_edit.js historically
manage the entire process of creating and editing stream
data (respectively).
Going forward both will delegate most of the subscriber-specific
pieces to either stream_create_subscribers or stream_edit_subscribers.
The stream_*_subscribers modules will be somewhat similar in
nature, but the way that we manage subscribers at creation time
is a bit different than how we manage subscribers at edit time.
This will help us avoid some duplicate code when
we use input pills for stream-create.
See the long comment in set_up_handlers() for
more context.
We also rename:
submit_add_subscriber_form -> subscribe_new_users
Ideally set_up_handlers() would also extract the
concept of clearing the pills as soon as you either
hit enter or clicked on the Add button, but our
current paradigm for clearing pills when you edit
subscribers for an existing stream on the Subscribers
tab is that we wait for the server to acknowledge
the request. I believe this is a bit of a misfeature,
but I am punting on that change for now.
This is mostly a pure code move. A few small tweaks:
* The create() function is new.
* The new module doesn't assume a `pill_widget`
global.
This module represents the truly re-usable code
that can be shared during these two user actions:
* edit-stream subscribers (now)
* create-stream subscribers (future)
In both situations the input pill has (or will have)
essentially the same behavior, and the next commit
will tighten up the abstraction.
(The two processes will both also use fairly similar
ListWidgets, but the mechanics of managing the list
are going to be different, so we do not intend
to keep around stream_subscribers_ui in its current
name. More on that later.)
This simplifies some of our dependencies.
As an example, we really don't want compose.js
to depend on stream_subscribers_ui.js, since
the former doesn't use any actual UI code from
the latter.
We also rename the two functions here:
invite_user_to_stream -> add_user_ids_to_stream
remove_user_from_stream -> remove_user_id_from_stream
(The notion of "inviting" somebody to a stream is
somewhat misleading, since there is really no invitation
mechanism; you just add them.)
Apart from naming changes this is a verbatim code move.
Finally, we eliminate a little bit of test cruft--the
`override` helper already ensures that a function gets
called at least once during a test.
Edit history of message was rendered directly without passing
it through rendered_markdown.js. Due to this several visual
features for dynamic elements like time, spoilers, mentions
etc were not available.
To fix above issues we pass the content of edit-history
through rendered_markdown before showing edit history modal.
Fixes: #16029.
Improves rendering of drafts to make it look more closer
to normal messages. This is done by passing the draft content
through rendered_markdown so that dynamic elements in the content
get updated before showing drafts modal.
Moves the profile avatar to the top when the viewport is narrowed down.
Tweaked by tabbott to add the 20px bottom margin in a more consistent
way, which also lets us deduplicate some code.
Fixes#21000.
d6fb439c7a removed the option to remove owner from the edit form available
to admins, but the option was still present in the edit form available to
the owner of bots in "Bots" section of personal settings. This commit
removes the option from form in "Bots" section of personal settings as well.
Previousy, we used to show or hide the digest weekday setting after
saving the emails setting, but now we show/hide as soon as we check
or uncheck the email setting checkbox like we do for other settings.
Notifies user when messages are not being marked as read through a
banner that lets them mark all messages in the narrow as read. Note
that the banner is only displayed if the user's actions, like
scrolling, would've actually marked the messages as read.
This avoids distracting the user when viewing a thread they've already
read.
tabbott has verified that if new messages come in, the banner will reappear.
Fixes: #18768.
There are a few instances where we check if messages can be marked
read and mark that list as read when scrolled to bottom. Using
this would be nicer and also this function can be extended later to
display a banner when messages are not being marked.
The class `sidebar-topic-check` has a minimum width assigned for the
`topic-resolved` icon to create an appropriate space for that column
whether or not there are resolved topics present.
Add a corresponding `margin-left` to align `more topics`
appropriately.
Show/hide scroll to bottom button when the last message is
not visible in the current scroll position.
We adjust the bottom offset of the button based on compose box
height.
Fixes#19862
We save the preferred theme in localstorage so that user doesn't
have to re-select the theme on every reload. Users on slow
computers might see flash of a theme change, if it happens.
This change was not aimed at popovers that use tippy. Since
popovers use light theme and tooltips don't, we use this
`not[data-theme]` selector to exclude popovers from being
affected by this change.
For filters that cannot be applied locally, we don't know if the
messages are still a part of the filter. So, we remove the
existing message that were updated and let `maybe_add_narrowed_messages`
treat them all as new messages to the filter.
This fixes the bug where existing messages that were present in
the narrow were not updated.
In the dark theme, disable the hover behavior to display sorting options
for actions column in tables (Which doesn't support this).
Matches existing behavior in light theme.
Fixes: #21137
Added a property `mouse_moved_since_typeahead` to the typeahead class
which tracks whether the mouse has been moved since the typeahead
menu appeared.
The hovered over menu item is highlighted on `mouseenter` only if
`mouseMoved` is true. Otherwise, the cursor is hidden temporarily.
Code substantially reorganized by tabbott.
Fixes: #21018.
For our Subscribers tab we want to enclose our
add-subscriber widget in a form for now, and we
continue to do so, but now we have the form tag
getting created in the parent template, not the
child.
Here is why:
We want to re-use our add-subscriber widget in an
upcoming commit for when you create streams.
In our create-stream UI, there is already an outer
<form>...</form> section of the HTML for the entire
process of creating a stream.
HTML does not yet you nest forms, and even though
browsers just silently ignore an inner form, we won't
want to create semantically incorrect HTML.
Therefore, we want the child template not to have
the form tags around them.
It's possible that we don't really even want to
enclose the input-pill widget and Add button inside
a form for the Subscribers tab, but tweaking that
for now is too risky. (We don't really take advantage
of the form tag in any meaningful way, since we
don't directly submit form data to the server, and
we can't use a single submit handler for the Enter
key and Add button due to some magic in our input
pills.)
We want to avoid submit handlers here, because we may
have embedded widgets that have their own forms or
buttons.
We use "finalize" here to distinguish the two Create
buttons related to streams. You hit one button to
start the UI and then the second button to finalize
the process.
I also fix the bad test idiom of clicking on the
sea-green button.
You don't start auto-completing user groups with an @,
so the previous placeholder text made no sense.
There might be a better way to do autocomplete in
these add-subscriber input pills, but that is beyond
the scope of my current efforts.
This adds tabindex='0' in anchor tags for allowing the message menu
popover box to be focusable using hotkey 'i' through keyboard.
This is a necessary follow up to
729c09074a, which removed the href
attribute from anchor tags to which click-handlers were attached,
which resulted in making them non-focusable as jQuery doesn't allow
anchor tags to be focusable without tab-index or href attribute.
Fixes#21125.
This seems to have no negative effect, and substantially improves the
visuals in situations where we're displaying a user's name.
While we're at it, switch to a relative font size.
When viewing a narrow such as a search or `sender:` view, where
consecutive messages in the view may not be consecutive in their
original stream/topic context, we should avoid displaying the messages
with a shared sender/recipient bar header, as that creates the
incorrect perception that they are consecutive.
Back in 2013 (bc8bc8567b), we
implemented this via the collapse_messages flag, but it appears more
recent refactoring (no more recent than
dbffb2a614) made it always true.
The original logic was incorrect, in that it only considered full-text
search views, and not other views with this property.
I originally planned to use the existing logic for
can_mark_message_read designed for this purpose, but I think there
might be product reasons why might want the logic to be independent.
Removes the 5px `margin-right` on images, replacing it
with a 5px `margin-left`. This change aligns the images
with the message content while making sure they do not
stick stick together in other layouts.
Add a margin below the subscription link for it to be visible when we
hover over links, where the browser will display the URL in the
bottom-left corner of the screen.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm typeahead and the mentions typeahead.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Fixes: #19865.
Previously the emoji_status set by the user would only be seen in a
few places, it was decided that it would be useful to show the
emoji_status in a couple of other additional places as well.
As such this commit uses the status_emoji template to show the status
emoji in the compose_pm pills. Due to the fact that we use the same
pills system to render in the user_group, we need to add a
conditional to prevent rendering there since the user status is not
valuable there.
Status emoji changes do not live update these, but neither do user
renames, so there's bigger problems if that's a concern.
Previously the emoji_status set by the user would only be seen a few
places, it was decided that it would be useful to show the
emoji_status in a few additional other places as well.
Use the status_emoji template to show the status emoji in the
message_body and also implement live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously the emoji_status set by the user would only be seen in the
buddy list, it was decided that it would be useful to show the
emoji_status in other places as well.
As such this commit uses the status_emoji template to show the status
emoji in the PM list and also implements live update behavior.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Previously, when the user clicked the `Add streams` icon in the
streams list sidebar, we provided a popover offering to create or
subscribe. This was confusing for users who did not have permission
to create streams.
Redirect users that don't have stream creation permissions
directly to browse streams without going through this popover.
Fixes: #20676.
Previously, if the user changes any stream color and updates it back
to the default color without reopening the change color popover, the
second color change didn't take effect.
Fix bug by destroying the colorpicker object and rebuilding it again
every time a color change is triggered by the confirm button.
Fixes: #21055
Previously, we would call `rerender_messages_view()` in order to
rerender messages after user renames or avatar updates. This would
lead to rerendering the entire message list for every change,
regardless of whether any specific message had changed or not.
This used to be acceptable because user renames and avatar updates
were rare events, however, as we plan to show user status emoji near
user names and updates to those would be more frequent than is
affordable, this commit implements
`rerender_messages_view_for_user(user_id)` which only rerenders
messages which have actually been changed.
This commit is, thus, both an optimisation for the existing code and a
prep-commit for the user status emoji.
Previously, we used to only calculate sender_is_bot, sender_is_guest,
small_avatar_url and background_color on the message_container via
build_message_groups (ie via .render, which also gets called from
.rerender_with_target_scrolltop).
This would mean that if we tried to use `_rerender_message` to update
just a single message (which is something we'd like to do, in order to
make rerenders more efficient), these values would not update.
(This could lead to avatars not light-updating properly).
As such, this commit moves assignment of these values into
`set_calculated_message_container_variables`.
This reverts commit 8e06335788 (#21048).
It regressed the ↑ and ↓ keys because drafts.drafts_scroll was not
updated to use ui.get_scroll_element. Also, styling the native
scrollbar as hidden is not the right workaround because the hidden
native scrollbar still exists and can be scrolled independently of the
SimpleBar.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In the topic changing UI, the 'Change later messages to this topic'
and other options in the drop down were cut off when selected in some
languages like Russian.
Make the selection box width adjust appropriately according to the
length of the text, and also place it on its own line unconditionally.
users.
With tweaks by tabbott to use the same approach we already use in the
"Move topic" modal to have the bottom margin for the color block match
that of the dropdown_list_widget itself, of having them share CSS.
Fixes#19739.
There is no problem in behavior of browser back button we open stream settings
overlay using UI elements since they are appropriately linked to "#streams/all",
"#streams/subscribed" and "#streams/new", but someone can directly go to a
link with "#streams" and in this case we want to fix the browser back button.
This commit replaces "#streams" entry with "#streams/subscribed" which is the
default section opened, such that pressing back when on "#streams/subscribed"
does not go to "#streams" and instead go back actually.
When we open settings overlay we first go to "#settings" hash and
then to "#settings/profile" or hash according to the last opened
section. Now when a user presses back button from "#settings/profile"
it goes to "#settings" which agains then changes to "#settings/profile"
and thus the browser back button does not work as expected.
This commit fixes this by replacing the "#settings" entry in history
with "#settings/profile" or to the hash as per last opened section,
using replaceState and thus there is no entry of "#settings" in history.
Fixes#19820.
We use button element instead of <a> element for the button used to change
stream permission. This change fixes the focus problem where the container
was focussed when closing the permission modal.
The problem here was because Micromodal focuses the element which was just
focused before opening the modal, on closing the modal. And in this case the
focused element before opening the modal was the "simplebar-content-wrapper"
element as <a> tah without href is not focusable element.
Related issue - #20223.
As seen in
https://chat.zulip.org/#narrow/stream/9-issues/topic/edit.20history.20bug/near/1320430,
clicking such a link takes you to the user's default view if the click
handler throws an exception before doing preventDefault().
There hrefs also have the negative effect of having your browser claim
that clicking the link will navigate you to the default view, which it
won't.
Comes with a linter rule to prevent future instances, since it seems
there are some recently added ones, though they are likely the result
of copy/paste.
Apparently, we were only dispalying the edit history option in the
message actions popover if the topic/content were changed. Fix this by
adding a small adjustment to the conditional to include stream
changes correctly.
Currently the emoji_status set by the user is only seen in the buddy
list, it would be useful to show the emoji_status in other places as
well.
As such this commit does the prep work of extracting a template which
will be used in all places that need to show the status emoji.
With refactor and minor edits by Yash RE.
Co-authored-by: YashRE42 <33805964+YashRE42@users.noreply.github.com>
Currently, the emoji_status set by the user is only seen in the buddy
list, it would be useful to show the emoji_status in other places as
well.
As such this commit does the prep work of decoupling the
selected_emoji style in user_status.css from the .status_emoji
style... by having it always override the value of "top".
I also clean up all the mutations of `user_ids`
in the calling code. We now have:
pill_user_ids
active_user_ids
user_id_set
user_ids
The new function is exported in anticipation of using
it from stream_create.js.
User should be able to tab from topic/pm input to textarea and back.
Moving `compose_top_right` button before the stream, topic and PM
input structurally in DOM but keeping them visually in the same
place, allows us to do so.
This is an unpredictable piece of css that shouldn't be part of
the code. It was introduced earlier in
04ece5e5c5
for `open-source` content which has been completely replaced.
The clarification is in Section 4.1:
Previously: ... from time to time engage additional third parties for
the purpose of providing the Services, including without limitation
the processing of Personal Data.
New: ... from time to time engage additional third parties for the
purpose of providing the Services, including without limitation the
processing of Personal Data, in accordance with Section 4.2 below.
This commit adds a method of marking an overlay as being meant to be
left open despite click events triggering that would normally close it.
This is to prevent the case where a user drags an image and "unclicks"
in an area where normally clicking would close the overlay.
This commit attempts to revert the lightbox state (at least
the pan/zoom part of it) when the lightbox is closed. The open()
function has been turned into a factory function so that the zoom
control which is instantiated on initialization of the lightbox can be
passed in to the on_close handler of overlay.open().
This PR changes how the Pan & Zoom feature of images displayed in the
attachment lightbox are handled.
The existing method of using a canvas element is replaced by the Panzoom
library (timmywil/panzoom). This library is lightweight and has 0
transitive dependencies.
This fixes#20759 where the issue is that the viewport of a zoomed image
was not expanding to fill the available space on the page. Switching to
this new library also solves several other UX issues:
* Images are no longer blurred when in Pan & Zoom mode.
* The zoom behavior itself uses focal point zooming: zooming occurs
where the cursor is on the image instead of at the center of the
image, reducing the need for extra panning.
* CSS transitions are used for a more visually pleasing experience
when switching images, toggling zoom off, etc.
* The library has the potential to open other file types which
leaves that option open for us in the future.
This change makes it easier to see who is present in a group private message conversation
when some of the users in it have long names.
We disable a stylelint rule for this line, because this particular -webkit prefixed CSS rule
works in all modern browsers including Firefox.
Fixes#21003.
It seems like orange is the loudest possible color to
denote a quasi-neutral-idle state, so we hope to
replace it with another color.
This commit does not change any styling.
I removed the sentences in the doc, since they are
kind of too vague to be useful. If we want to say that
the idle state is correlated with the half-orange
circles in the buddy list, then we want to say that
more specifically.
This function is not used currently after we removed the
"Group PMs" section from right sidebar in 43e5b2d28b.
This commit also removes presence.is_active function as it
was only used in buddy_data.huddle_fraction_present.
Now checking for custom trigger keys will happen during `keydown`
instead of `keyup` so that if the key is printable, `preventDefault`
can prevent it from appearing in the compose box.
This fixes the case when jumping to topic, would eat up any space
or new line after the cursor, due to wrong splitting around the
cursor, which was a result of using the printable custom trigger key,
the ">", in contrast to a non printable one like Enter.
The problem was that custom trigger keys like `>` that the browser's
default behavior is to type (vs. others like RightArrow where that
isn't the case) can result in extra characters being emitted, which
is not wanted.
This commit updates the error message shown on sending a message
with no topic in an organization with mandatory_topics setting
set as true to match the error message in API.
Autosize library can miss resize of compose-textarea when
compose is collapsed / expanded while preview box is displayed
and compose-textarea is hidden. So, we force a autosize.update
of compose-textarea, when user exits markdown preview, to ensure
that the textarea is of correct size.
Fixes#19353
Instead of blindly adjusting `compose-textarea` on resize,
we adjust the height of `compose-textarea` or `preview_message_area`
based on which is visible.
This commit creates the function warn_if_topic_resolved that checks if
the topic to which the user is composing is resolved or not. First it
checks if the stream exists and then if the topic name starts with the
RESOLVED_TOPIC_PREFIX. If the conditions are true, a warning banner is
shown to the user.
It also shows to the user a button to unresolve the topic, if he has
the permission to do so.
Fixes#20584.
The previous internationalization approach didn't support languages
with a different word order than English.
We also switch to using "moved" to explain topic/stream moves,
consistent with how the message feed explains it.
The recent commits to display the previous and new streams for a moved
message did not correctly handle messages moved multiple times.
To do this, we need to do a somewhat awkward loop, at least until we
modify the API to do this loop for us.
This commit fixes two things -
- We use the exact same color that is used for stream name in
day mode.
- Previously, we were passing black color explicitly to the
stream_privacy_icon template. This commit changes it to pass
different color in the night mode which is the same used for
stream name in night mode.
`bookend_top` is already defined firmly for `group` in
`add_subscription_marker`, so no need to redefine it.
`bookend_bottom` is no longer used anywhere in the codebase. Not
sure what the history is here.
We need to mark trailing bookends differently to identify them
in DOM easily. This fixes a bookend replication bug which can
happen sometimes when rendering.
We move the stream subscribed/unsubscribed bookend info from
js files to bookend handlebar.
Tweaked by tabbott to override the check-templates indentation logic.
This effectively reverts part of
70d444a8eb. While it's correct that we
want to render this bit of Handlebars template early, it was not
correct to move all compose box initialization earlier.
Do the same thing we do with the left/right sidebar container
templates, which is to render them directly in `ui_init.js`.
Fixes#20778.
In English, compound adjectives should essentially always be
hyphenated. This makes them easier to parse, especially for users who
might not recognize that the words “web public” go together as a
phrase.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit refactors the code to directly pass sub object to
selected_stream_title template instead of passing name, is_web_public
and invite_only as different parameters.
The content which is scrollable is moved left by the width of the
scrollbar when scrollbar is visible. The navbar, floating recipient bar
and composebox doesn't move. We reduce their width by scrollbar width
to adjust for the reduced width of the scrollable content.
Since floating recipient bar is center aligned (with margin: 0 auto)
we also have to move left by half the scrollbar width.
Group css classes having the same value being assigned together. This
makes the code easier to understand.
Added a negative `outline-offset` of the same width as the grey border
for the blue selection outline around the `draft-info-box`.
This removes the gap between the blue box in the active state, while
the unselected `draft-info-box`es look the same as before, with a grey
border.
Fixes: #20950.
N-Shar-ma
Sahil Batra
Anders Kaseorg
Swapnil Gore
Ivan Toymentsev
Aman Agrawal
Ganesh Pawar
Rishant Rokaha
Lauryn Menard
yogesh sirsat
sahil839
anurastogiji
Nikhil Maske
Tim Abbott
om2137
Julia Bichler
Alex Tereschenko
sayamsamal
Lauryn Menard
ritikBhandari
Alex Vandiver
jai2201
evykassirer
Alya Abbott
YashRE42
Christopher Chong
Riken Shah
aparna-bhatt
Gaurav Pandey
aparna-bhatt
madrix01
Raghav Luthra
Advait J
Harshit Agarwar
NerdyLucifer
Lani
somesh202
Tanya Singh
Dinesh
Somesh Ranjan
Adam Sah
Greg Price
Greg Price
George A. Michel
Austin Riba
Sdrummolo
Steve Howell
Archisman Das
Palash
Heidi Ahlberg
ditsuke
Rishabh-792
SantamRC
My-Name-Is-Nabil
Biki-das
strifel
Suyash Vardhan Mathur
Lauryn Menard
prashantpaidi
Greg Price
Junchen Liu
Austin Riba
Yogesh Sirsat
Mateusz Mandera
Purushottam Tiwari
Jai soni
AnushaNathRoy
Mr.mad
Parth
Priyam Seth
