This was just debugging logic working around the fact that vdom.ts was
not originally implemented in TypeScript, and should not be polluting
our types.
This commit renames the realm-level setting
'signup_notifications_stream' to 'signup_announcements_stream'.
The new name reflects better what the setting does.
This commit renames the realm-level setting 'notifications_stream'
to 'new_stream_announcements_stream'.
The new name reflects better what the setting does.
Now whenever we initiate sending a message, we save / update its draft,
which is deleted on a successful send. Earlier, we did this only for
locally echoed messages. Hence a non locally echoed message's draft
would remain, if created in the timeframe between initiating send and
receiving the same message from the server, which can be significant
for slow connections.
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a second step, split
out the subset of fields that pertain to the entire realm.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For spectators, the chunk of page_params that originates from
do_events_register isn’t assigned until ui_init.js. That means the
TypeScript type of page_params is mostly a lie during module load
time: reading a parameter too early silently results in undefined
rather than the declared type, with unpredictable results later on.
We want to make such an early read into an immediate runtime error,
for both users and spectators consistently, and pave the way for
runtime validation of the page_params type. As a first step, split
out the subset of fields that pertain to the current user.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit extracts the edited notice computation logic of
edited_in_left_col, edited_alongside_sender and edited_status_message
to a new function - set_edited_notice_locations and calls it right
after the method merge_message_groups.
This is a preparatory commit, and is done since theses three variables
were previously wrongly initialized in the beginning for live messages
received.
We also introduce a modified flag to decide whether to display the
edited notice or not. This is useful since now we are computing
the edited notice values even when messages are not edited, and
hence we show the notices only when the modified flag is true.
The previous batch of improvements to this code path in
6562ea94e4 introduced a race bug where:
- You navigate to a narrowed view; Zulip renders cached data from
`all_messages_data` that we know is current, but
`fetch_status.has_found_newest` is initialized to `false`
nonetheless.
- The bottom is visible, triggering the check for whether the view
should be marked as read.
- `fetch_status.has_found_newest` is still `false`, and so we
incorrectly refuse to mark as read.
- We finish fetching data from the server, do the background rerender
for that (with no changes), but that doesn't trigger a re-check for
whether the bottom is visible.
There's several ways to address this, but most correct to me is to not
check fetch_status in this particular code path.
The same reasoning applies to the navigate.js call sites.
This should help reduce the risk of hitting rate limits when users
have a very large number of messages to fetch via this mechanism.
Inline the `messages` variable that was only used in one place while
we're touching this.
I was not able to reproduce obviously badly broken behavior from these
logic bugs, but after the renaming of message_viewport helpers in the
last few commits, it's clear that this logic was trying to check if
we're actually at the start/end of the possibly message feed, not just
the rendered portion, and doing so incorrectly.
So far, there were 2 separate turndown rules for code blocks; one for
general ones, and the other for Zulip message code blocks.
Now the filter rule has been generalised to handle both cases together.
As a side effect, the bug where partially copied Zulip code blocks
lost formatting on pasting has been fixed.
As discussed in the new comments, we had a bug where the
system-initiated animated scroll that happens when the compose box
opens as a result of narrowing would race with the internal
rerendering that occurs when the message_fetch request asking the
server for additional data returns.
The correct fix for this is just to open the compose box, if we're
going to do so, before setting the user's scroll position in the
narrowing/rendering process.
This ends up being a UI improvement (in that the compose box is
available for typing a bit earlier) as well as avoiding both the risk
of this race as well as the bad UX of adjusting the user's scroll
position multiple times as part of entering the view.
This does not address an as-yet-unknown bug wherein the animated
scroll that occurs when opening the compose box, when racing with a
background rerender, results in a bogus ending scroll position, though
it's easy to see how that might occur given that rerendering does
clear the DOM briefly.
Needed for typescript, because we want to preserve
types, so instead of mutating a message object,
we can instead calculate return these values
for a message object before it's created in full.
This commit also renames apply_markdown
to render, see this comment
https://github.com/zulip/zulip/pull/28652#discussion_r1470514780
Since notifications have limited space for the contents of a message,
a quote from a previous message, or elsewhere, can take up most of the
notification, leaving little room for the actual message, and reducing
the usefulness of the notification.
To fix this, we collapse blockquotes and "user said" paragraphs to make
space for the actual message.
From `get_current_nth_hash_section` `get_nth_hash_section()` is
extracted to allow for reuse for any hash. The indexing is also changed
to 0-based and negative indexing also works now.
This is a prep commit for the next, where `get_nth_hash_section()` will
be used in a new function with negative indexing.
Also, makes small updates to `next_plan_forms_support.html`.
Removes unneeded "btn" and "btn-default" classes, and updates
the placeholder text for the input as not marked for translation.
So far, when ordering typeahead suggestions, any query matches that did
not occur at the start of the target string were considered equally. So
for example, for the query "ok", "squared_ok" and "smoking" were
allotted equal priority, which does not make sense.
Now, matches from a word boundary (space, hyphen, underscore or slash)
are given priority (after exact matches and beginning matches), so that
in the above example, "squared_ok" is regarded as a better match than
"smoking".
Since recipients' sorting is complex, and needs word boundary matches
separately for decoupled sorting post triage, `triage_raw` is extracted
from `triage` to return the raw matches.
Fixes: #24127.
Though the correct mapping for Alt in Mac is Option, we had so far been
mapping it to Command, since for the 2 pre-existing shortcuts that used
Alt, Command was the only key that worked on Mac. However, these are
exceptions.
Now we map Alt to Option, and handle the 2 exceptions separately, using
data attributes on those shortcut elements.
This is a prep commit for introducing a hotkey that uses Alt / Option.
This will prevent any message we want to select after narrowing
from being offscreen entirely or partially.
Steps to reproduce the bug:
* `./manage.py populate_db -n 3000 --max-topics=2`
* Narrow to a stream and scroll high up.
* Align two recipient bars together with nothing between them.
* Click on the first recipient bar after keeping the selected message
on the second recipient bar.
* You will see that the selected message is not in view.
Fixes#26774.
We don't need the today argument anymore since every value passed to
it was a new Date() except the tests where we are using MockDate now.
All message view has `in-home` filter and is not empty.
If there are no terms provided, we set filter to display
all messages (including muted streams/topics).
We make it mandatory to provide terms to Filter.
For compose state variables `last_focused_compose_type_input` and
`message_type` that are assigned non-boolean values on user interaction,
`undefined` is the semantically better choice than `false` for
initialisation, to avoid incorrect boolean implications.
When pasting any code without any newlines, whether from a code block or
a code span, it will always be pasted as inline code.
That is, a line of code copied from within a code span will retain code
span formatting on paste, and a line of code copied from within a code
block will be pasted as inline code, instead of a 1 line code block.
Earlier, the tests for compose formatting were verbose, hard to read as
well as extend, and overly granular, without even having the ability to
test the final text selection or the cursor position.
Now, new test helpers, `init_textarea_state` and `get_textarea_state`,
have been added, enabling the tests to be more concise and readable,
while also being more powerful. A representative string alone now
describes the textarea state (the text and the selection / cursor),
making each test case as easy as defining the initial state as a string
and comparing the expected state post formatting with another string.
These new tests helped surface a couple bugs which have been fixed in
preceding commits.
Earlier, a new banner would be showed for each mention of the same
private stream in the compose box. This commit fixes that by checking
if the private stream warning banners already shown include the private
stream just mentioned, and if so, not showing a new banner.
This implementation is in line with the one for warnings for mentions of
users not subscribed to the current stream.
Fixes: #26914.
We previously allowed adding pills for inaccessible user by typing
the email manually. This commit updates it to handle inaccessible
users like we handle invalid emails.
Operand is a confusing name because this
data structure has an attribute *called*
operand. This commit renames references to
this structure to "term", short for "search
term".
For spectators, page_params.custom_profile_field_types has not been
initialized yet at module load time.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Some files already were using `noop` in place of `() => {}`.
It's both clearer what it means and is easier to type.
This updates all test files to fully use `noop`, and
adds a shared import from the test lib file.
The "user_group_name_dict" value for the old group name key
was not deleted and this led to a bug where the stream creation
UI was incorrectly showing about a user group already existing
with the old group name.
Fixes#28108.
This commit adds code to not show typing notifications for inaccessible
users as the user would not have any information even if we show them
as the name shown would be "Unknown user".
Inaccessible user names are shown as "Unknown user" in the
reacted users list and tooltip.
This commit removes the call to `is_known_user_id` since we
may have reactions data from inaccessible users. And it is
fine to remove the `is_known_user_id` call anyways, because
it was added to ignore showing reactions from deactivated
users when the client did not have data about them, but now
the client has data about deactivated users.
So we anyways do not expect unknown user IDs in cases
other than inaccessible users for which we have to show
the reactions by showing their name as "Unknown user".
This commit also updates the comment for "is_known_user_id"
function accordingly.
We do not update the name for mention pills of inaccessible users
and keep it same as it was in the message content, and we show
the "Unknown user" popover on clicking the pill.
This commit sets the client capability value to not pass
unknown users data in the webapp and also does some changes
to avoid errors while loading the web-app home page.
This commit only does some basic webapp changes to not show
inaccessible users in sidebar and we would need need more
changes to make the web-app work as expected which will be
done in further commits.
The "User groups" panel is now removed from settings overlay
and we instead use new "#groups" UI.
This commit also makes some changes to tests to ensure coverage
for pill_typeahead.js which was previously done by
settings_user_group_legacy.test.js. We have still not got
complete coverage on user_pill.ts as we have removed
settings_user_group_legacy.test.js, but we just add the file
to EXEMPT_FILS list for now and will handle it in future.
Fixes#28012.
Earlier, the event sent when an onboarding step (hotspot till now)
is marked as read generated an event with type='hotspots' and
'hotspots' named array in it.
This commit renames the type to 'onboarding_steps' and the array
to 'onboarding_steps' to reflect the fact that it'll also contain
data for elements other than hotspots.
We have already fixed the actual bugs that were resulting in client
receiving presence data for unknown user, so we can remove the
blueslip logging and just skip the unknown users.
To extend the drag and drop upload area to blank areas after sidebars,
we now detect the drag/drop event on the entire ".app" division.
We also change replace `width` and `height` css properties with
`min-width` and `min-height` properties respectively, to make sure
that the ".app" div spans the entire width and height of the viewport.
Fixes: #27550.
When a user is replying to a message while in a search view, we now warn
them that the full conversation is not visible and urge them to go to
the conversation they are composing to, so they can see the complete
conversation. On narrowing to that conversation, the banner is removed.
Fixes: #25893.
This fixes a very rare exception seen in production, which the
previous assertion allowed us to understand was possible in a rare
race, now documented in comments.
Earlier, when a topic had less than 15 participants,
the @-topic typeahead was not visible. It should be visible
irrespective of the 'realm_wildcard_mention_policy' setting
when the participant count is not greater than 15.
The participant count for a topic can't always be calculated
accurately in the client as some of the messages might still
be loading.
We show @-topic in the typeahead whenever it might be possible
to use it.
We will give an error later if you aren't allowed to use it.
Fixes#27852.
This prep commit renames:
* 'stream_wildcard_mention_allowed_in_large_stream' to
'wildcard_mention_policy_authorizes_user' because the function
checks if the sender is allowed to use wildcard mentions based
on the 'wildcard_mention_policy' setting, and we plan to use that
for topic wildcard mentions too.
* 'stream_wildcard_mention_large_stream_threshold' to
'wildcard_mention_threshold' because this value is going to be
used as a threshold value for the max number of subscribers and
participant count allowed for stream and topic wildcard mention
respectively.
Earlier, for the desktop notifications having latex math
like "$$1 \oplus 0 = 1$$, the notification had the math
included multiple times.
This commit fixes the incorrect behavior by replacing
the KaTeX with the raw LaTeX source.
Fixes#25289.
This commit introduces non-intro hotspots.
They are a bit different than intro hotspots in the
following ways:
* All the non-intro hotspots are sent at once instead of
sending them one by one like intro hotspots.
* They only activate when a specific event occurs,
unlike intro hotspot where they activate after the
previous hotspot is read.
Rules followed:
1. Bold and highlighted background if the mention was processed
as a mention that includes you.
2. Bold personal mention (but not highlighted) if you were mentioned
but not subscribed at the time.
3. Otherwise not bold, no highlighting.
As we plan to keep the mention pill CSS the same if a user
was mentioned via that personal/wildcard/usergroup mention
irrespective of whether the user is subscribed or not, we use
usermessage flags to determine when to add 'user-mention-me' class.
Fixes#27654.
Now, the topic wildcard mention follows the following
rules:
* If the topic has less than 15 participants , anyone
can use @ topic mentions.
* For more than 15, the org setting 'wildcard_mention_policy'
determines who can use @ topic mentions.
Earlier, topic wildcard mentions followed the same restriction
as stream wildcard mentions, which was incorrect.
Fixes part of #27700.
We simplify the banner message by replacing the
"stream wildcard mentions" text with `"@stream mentions`,
`"@-all mentions"`, or `"@-everyone mentions"` text.
This commit updates the backend code to allow changing
can_access_all_users_group setting in development environment
and also adds a dropdown in webapp UI which is only shown in
development environment.
When toggling off link formatting, it is assumed that the description
does not contain [ and ] characters, and the url does not contain ( and
) characters.
Co-authored-by: N-Shar-ma <bablinaneh@gmail.com>
Note that toggling off spoiler formatting works if either all the
content inside, or the header (if it exists) or both are selected.
Co-authored-by: N-Shar-ma <bablinaneh@gmail.com>
Note that toggling off, only works for code blocks without a specified
language. So toggling formatting off only works for code blocks like:
```
code
```
and not:
```javascript
code
```
Co-authored-by: N-Shar-ma <bablinaneh@gmail.com>
We don't show emoji icon on message on width range even if the
logged in user is not the sender, which causes popover to not
be displayed since the reference is not visible.
To avoid such case in future, we just check if the emoji icon is
visible and if not fallback to the ellipsis icon for reference.
Until now, when a user quoted and replied to a message, even while
editing another, the quote would be inserted into the compose box. There
was no way to quote into the edit box.
Detecting the edit box to add content too was tricky, since on opening
the message actions popover, that message would be selected, while the
edit box would lose focus.
Now we don't shift focus on opening the message actions popover, keep
track of the last focused textarea and add the quote content to it if
if it's still in the DOM (if the user has not cancelled the editing).
Fixes: #20380.
Up until now, the currently selected message was the one that was always
quoted. Now if there's a message_id passed in, we'll quote that message
instead, otherwise we'll fall back on the selected message.
This is a prep commit for allowing quoting and replying while editing a
message sent earlier.
Up until now, the currently selected message was the one that was always
responded to. Now if there's a message_id passed in, we'll use that
message instead, otherwise we'll fall back to the selected message.
This is a prep commit for allowing quoting and replying while editing
a message sent earlier.
Earlier, a 'large @-mention notification' warning that pops up
for stream wildcard mentions was shown for topic wildcard mentions
too, which is incorrect.
This commit fixes the incorrect behavior. We no longer show the
banner for @-topic mentions.
We don't need a banner for @-topic mentions, as those are much less
likely to be used without thinking about it and would rarely be spammy
for a lot of people.
Fixes#27767.
date-fns-tz does not handle daylight saving time correctly, and can be
replaced with modern browser APIs.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Tim Abbott
Prakhar Pratyush
N-Shar-ma
Anders Kaseorg
Alex Vandiver
roanster007
Varun Singh
Aman Agrawal
evykassirer
Lauryn Menard
Sahil Batra
Shubham Padia
CIC4DA
Aditya Kumar Kasaudhan
Anuja Patil
Evy Kassirer
Vector73
Sayam Samal
Riken Shah
Julia Bichler
Karl Stolley