- Removes `tip` block that does not apply to the "Send a scheduled
message now" section.
- Adds relevant keyboard tips.
- Adds "Related articles" section.
- Adds `message_handle_match` function to handle new pattern for
relative help links to "Drafts" and "Scheduled messages" for logged-in
users: `{relative|message|drafts}` and `{relative|message|scheduled}`.
`remove_denormalized_recipient_column_from_data` removes the
`recipient` data from `zerver_userprofile`, but did not remove it from
`zerver_userprofile_mirrordummy`, which was later appended to the list
of `zerver_userprofile` objects. This led to failure when inserting,
as the mirrordummy objects still tried to reference their previous
`recipient_id`s.
Move the merging of the two sets earlier, before we call
`remove_denormalized_recipient_column_from_data`.
If there are two huddles, with users A + B + C + D and A + B + C, and
user D is deleted, it is replaced with a mirrordummy user. If
mirrordummy subscriptions are not included in exports, then the two
huddles have duplicate member sets, and will not be able to be
imported successfully.
Include huddle subscriptions for mirrordummy users in exports.
Specifically when it's the last operand of the search
filter. This makes the first line of search results
more consistent with the lines that come after.
`selected_recipient_id` is supposed to be an id,
not a stream name. This function is currently
only ever called for direct messages, so there's
no present user-facing bug.
This mainly fixes error related to if checks like - `if ($jquery[0] !==
undefined)` which is not a good way to check for existence of jquery
objects instead we should check the length of jquery collections for
these if checks.
`modals_handle_events`.
We are not using the `_e` parameter here since this commit `4a3211d`, so
I removed this parameter from the `modals_handle_events` function.
Since `list_widget.render_item` accepts the parameter of type `Item` and
not `Key`, therefore we should pass the actual item instead of just
plain id to the `render_item` function here.
itself.
We were checking for the undefined value of `$html_item` but this
variable is always true since `$.find` never returns an undefined value
and it returns a JQuery collection instead.
So we need to check the length of that JQuery collection here to make
sure that the condition works as expected.
After migrating to TypeScript, we don't need to manually validate the
configuration passed to the `ListWidget`, that's what typescript complier
will do for us, hence I removed `validate_opts` and `valid_filter_opts`
functions.
We should directly set the value of `$scroll_container` when making the
`meta` object in `list_widget` instead of setting it up later in
`set_up_event_handlers` function which gets called anyways on
widget initialization. This allows us to not make an incomplete type
object which typescript will complain about when we migrates this module to
TypeScript.
This is a prep commit for typescript migration of this module. In this commit
I made all the users of ListWidget pass generic sort functions like 'alphabetic'
and 'numeric' explicitly to avoid type conversions which we may need when moving
to typescript, also it simplifies our `set_sorting_function` a bit more.
This is a prep commit for moving towards typescript migration of this module.
We should make `get_item` required on `list_widget` because its intended to be
used with a set of keys and then hydrate the keys lazily. Also this will help
us to avoid writing messy if-conditions while filtering and sorting and make
our life much easier when we migrate to TypeScript.
I added a `default_get_item` function which is just n identity function and
also refactored some code to make use of default get item.
We should keep methods of `list_widget` generic and independent of outer modules
data types and hence I added this parameter to get insert index to make
`insert_rendered_row` work with any list we create and not only `topic_list`.
This is a prep commit for migrating `list_widget` to TypeScript, In this
commit we declare all our methods for the widget directly inside `widget`
object to avoid making an incomplete object when we add a type for our widget.
Fundamentally, we should take a write lock on the message, check its
validity for a change, and then make and commit that change.
Previously, `check_update_message` did not operate in a transaction,
but `do_update_message` did -- which led to the ordering:
- `check_update_message` reads Message, not in a transaction
- `check_update_message` verifies properties of the Message
- `do_update_message` starts a transaction
- `do_update_message` takes a read lock on UserMessage
- `do_update_message` writes on UserMessage
- `do_update_message` writes Message
- `do_update_message` commits
This leads to race conditions, where the `check_update_message` may
have verified based on stale data, and `do_update_message` may
improperly overwrite it; as well as deadlocks, where
other (properly-written) codepaths take a write lock on Message
_before_ updating UserMessage, and thus deadlock with
`do_update_message`.
Change `check_update_message` to open a transaction, and take the
write lock when first accessing the Message row. We update the
comment above `do_update_message` to clarify this expectation.
The new ordering is thus:
- `check_update_message` starts a transaction
- `check_update_message` takes a write lock on Message
- `check_update_message` verifies properties of the Message
- `do_update_message` writes on UserMessage
- `do_update_message` writes Message
- `check_update_message` commits
Previously clicking on a message in search results opened
the compose box. This was not great, because search views
show messages outside of their context, and replying to a
message without the context of possible more recent
messages sent to that narrow can result in a bad experience.
This commit prevents the composebox from opening on click and instead
moves the user to a near view for the message, and similarly with the
enter keyboard shortcut.
Fixes#21217.
Removes the `assert_number` over defensive function which was being used
for validating the type of `stream_id` but now that this module is
converted to TypeScript we do not need this function anymore since
typescript compiler will do the type checking for us.
In this commit, we have replaced `build_stream_list()` with
`update_streams_sidebar()`. This change avoids zooming out from the
"more topics" view when toggling your subscription to a different stream.
It also triggers a forced rerender of the left sidebar only when
unsubscribing from the currently active stream. The stream list will be
updated once the user zooms out.
The `stream_list.build_stream_list()` function is responsible for
rendering the stream list in the left sidebar. Previously, it uses
`topic_list.clear()` to clear the `active_widgets` that tracks active
stream(s) in the left sidebar. This led to a bug where rendering stream
list after adding or removing a stream through `build_stream_list()`
while a stream was zoomed in ("more topics" clicked) didn't fully exit
the "more topics" view. So clicking "BACK TO STREAMS" throws an exception
with the message "Error: Unexpected number of topic lists to zoom out"
because `active_widgets`, cleared by `topic_list.clear()`, became
inaccessible.
To address this issue, instead of clearing the topics list with
`topic_list.clear()`, the code now ensures the closure of the zoomed
stream by using `topic_zoom.clear_topics()`. This change ensures a
proper exit from the "more topics" view and avoids the exception.
Fixes#25670.
The long-term idle topic participants are soft-reactivated
after email/push notifications are sent due to @topic mention.
The reason being that, generally, @topic mentions are going to
reach a small set of users who have a decent chance of being
reactivated by the notifications.
This commit completes the notifications part of the @topic
wildcard mention feature.
Notifications are sent to the topic participants for the
@topic wildcard mention.
The previous function was poorly named, asked for a
Realm object when realm_id sufficed, and returned a
tuple of strings that had different semantics.
I also avoid calling it duplicate times in a couple
places, although it was probably rarely the case that
both invocations actually happened if upstream
validations were working.
Note that there is a TypedDict called EmojiInfo, so I
chose EmojiData here. Perhaps a better name would be
TinyEmojiData or something.
I also simplify the reaction tests with a verify
helper.
David Rosa
AcKindle3
Alex Vandiver
evykassirer
Lalit
Karl Stolley
abdullahm1
Hemant Umre
Prakhar Pratyush
Steve Howell