When users needed to add a new task in the todo widget, they would type
it in the field at the top, but the task would be appended to the list,
showing up at the very bottom, which can seem unintuitive.
Now the `add-task-bar` is at the bottom of the list, so that when a new
task is added, it'll appear right where it was typed. The task field
would then shift lower.
Uptil now, users could add tasks to a todo widget only after creating
it through the `/todo` command in the compose box.
Users can now add an initial list of tasks using the `/todo` command,
with each task on a new line in the compose box, where the 1st `:`
would separate a task from its (optional) description. Example:
`/todo\nTask1:description1\nTask2 without description`.
Fixes part of #20213.
Users can now name task lists by providing the task list title in the
`/todo` command on the same line. Example: `/todo School Work`. If no
title is provided by the user, "Task list" (which is also the
placeholder) is used as default.
The author of a task list can later edit / update the task list title
in the todo widget, just like the question in the poll widget.
Fixes part of #20213.
The schema now ensures extra data is validated according to the widget
type. This also makes it easier to modify the extra data for any widget
or add new widget types in the future.
Shift-clicking a link on most browsers should open the link in a new window,
not navigate inside the current tab, just like ctrl-click opens in a new tab.
This fixes the bug where on hovering / selecting an emoji picker search
results emoji, invariably its canonical name would show / be used, which
is not always the same as the matching alias. For example, searching for
"swe" would show the "sweeping" emoji, but its canonical name is "broom"
which can be a confusing search result for "swe".
Update the Filter class to use "channels" as the canoncial operator
for public stream searches and web-public message fetch narrows,
but keep using "streams" for user-facing text and URLs.
When searching, "channels" does not create any suggestions until
a colon is added and then it shows suggestions with "streams". And
when a search string with channel as an operator is entered, then
it is replaced by "streams" as well.
Part of stream to channel rename project.
Update the Filter class to use "channel" as the canoncial operator
for streams, but keep using "stream" for user-facing text and URLs.
When searching, "channel" does not create any suggestions until
a colon is added and then it shows suggestions with "stream". And
when a search string with channel as an operator is entered, then
it is replaced by "stream" as well.
Part of stream to channel rename project.
Updates filter_with_new_params so that the terms used to update the
current narrow filter are the canonical version of the terms. This
assures that the adjustments we're making are correct.
Updates filter.test.js to use constants when checking the message
type ("stream" or "private") as this eliminates overlap with the
search/narrow operator "stream" and is useful prep for eventually
updating the frontend code to use "direct" as the message type
for direct mesages.
Part of stream to channel rename project.
This change allows different types of lists to
be rendered properly inside the {{start_tabs}} /
{{end_tabs}} block in markdown.
Fixes zulip#29669
Suggested-by: Lauryn Menard <github:laurynmm>
Change the way scrolling was implemented by scrolling to the success
message. Done this by calling the scrollIntoView() method with the
success message id, it scrolls the element with id into the visible
area of the browser window.
This way the confirmation banner becomes visible, scrolling the
invitation modal to the top when a user sends invites or generates an
invite link.
Previously, it did not scroll, as we were passing the id of the whole
dialog element to the get_scroll_element function.
Fixes#28906.
Clean reactions and set message_reactions in process_new_message.
Earlier, message_reactions was being set
after the predicate for the narrow was built,
as a result functions called while building the predicate
could not access it.
This commit converts the radio buttons (for
selecting email/link) to tab
components in the user invite modal.
The selected tab is in focus by default and arrow keys
can be used to toggle the selected tab.
Appropriate tooltips are shown when a tab is disabled.
Fixes#29392.
This commit removes the unnecessary condition for a linked image to have
a label when checking whether to skip an image preview if its generating
link has already been copied.
Now whenever the bottom of the feed is visible, we always scroll to the
message/s just sent by the current user, updating the selected message
if necessary.
Scroll behaviour for messages sent by other users remains unchanged.
Fixes: #23298.
The blocks were originally separated by some code for seemingly no
reason, so now the 2nd block is brought up and combined into the first.
An old irrelevant comment is also removed.
When a long message is restored from a draft (or scheduled messages),
its end, and the cursor placed there, used to be out of view, giving the
impression that the message was not focused, when it actually was.
This is fixed by always scrolling the cursor into view.
This commit renames "View message source" to "View original message".
The meaning of "original" in this context is very similar to what
source/source code means in software jargon, while being easier to
understand and translate for a non-tech savvy user.
The simplebar core documentation, recommends to not style the element
initalising the simplebar at all and use an inner element instead.
Following the recommendation, we move the max-width property from the
popover tippy options, to the `.simplebar-content` element via the
`--popover-menu-max-width` custom property.
While doing so, we also simplify the max-width to `350px`, since the
responsiveness for smaller screen is already been taked care of in the
shared popover styling.
This prevents the issue where the content overflows and gets hidden
instead of wrapping, when the width of the popover reaches the set
max width (if any).
Following ca9b1060b7, we allow the content of popover menu items to
control the width of the popover.
While using `white-space: nowrap` works, we should instead use the
`max-content` intrinsic sizing so that, if necessary, we can still
provide a `max-width` to the popover which would then force the popover
menu content to wrap.
Added `tippy.js/dist/border.css` along with some custom CSS override,
to add arrows which inherit the border color and width of the popover,
while also supporting all placements.
Also consolidates the CSS styling of the popovers to the `tippy-box`
element, which is the recommended way to theme the element according to
https://atomiks.github.io/tippyjs/v6/themes/#creating-a-theme.
This further helps in unifying the styling of the popover and the arrow,
and prevents inconsistencies such as shadow of the popover being casted
onto the arrows.
We now always show the scrollbar in invite modal body if it is scrollable.
This avoids confusion and makes it clear that some options are out of view.
Fixes#29393.
Previously, when stream settings were updated, without opening the
compose box, assertion error were thrown.
This error was a result of a regression in compose_recipient, due to an
extra assert statement added during its typescript migration in
25ff0d4418.
This is fixed by removing the statement.
Since the type of request_method(AjaxRequestHandler) has
been extended in the previous commit.Consequently the 'data'
field of 'request_method' has to be typed such that it
satisfies this change.
Because request_method's type can also be 'typeof patch' which
does not accept undefined 'data' field, I haved 'omit'-ted
'undefined' from 'data's type in function signature to satisfy
TypeScript.
Now ,in support of the changes I have made to two different function
sign(namely setting_ui.do_settings_change,dialog_widget.submit_api_request)
I am stating some points about data field inside these respective
function signs.
1.settings_ui.do_settings_change: For this 'data' was actually never
undefined. Each function call has a 'data' object passed( with one
or more fields).
2.dialog_widget.submit_api_request: For this case many function calls
actually didn't have 'data' field (ie.'data' was undefined).
BUT,for those cases it was defaulted to '{}'(see function sign).
So effectively 'request_method' didn't recieve an undefined 'data' for
this case too. I have removed the defaulting and passed '{}' in the
function calls for those cases, which effectively does the some job,
but satisfies the type.
For both these cases 'data' field isn't undefined and hence an Omit,for me
makes sense.
Type AjaxRequestHandler is used for typing request methods
(like channel.get, channel.post etc.)Use cases include
'request_method' parameter in settings_ui.do_settings_change
and dialog_widget.submit_api_request.
Problem with the type definition:
The current type definition( ie. 'typeof call' ) satisfies every
'request_method' type EXCEPT channel.patch request.One can notice
the difference b/w 'call' and 'patch' function in channel.ts .
Hence,We need to expand the AjaxRequestHandler type.I have unioned it
with 'typeof patch' is account for the case when 'request_method'parameter
is of type channel.patch.
Discussion:
https://chat.zulip.org/#narrow/stream/6-frontend/topic/setting_ui.20do_settings_change/near/1754557
Mateusz Mandera
Tim Abbott
N-Shar-ma
Olivier FAURE
Varun Singh
Aman Agrawal
Karl Stolley
Lauryn Menard
PieterCK
joaoafonso07
Kenneth Rodrigues
Kislay Verma
Jose Corte
Sayam Samal
Shubham Padia
tnmkr
roanster007