This commit adds support for using the
x-curl-examples-parameters parameter in OpenAPI
data to fetch curl examples configuration. This
also contains any descriptions necessary for each
example, and directly generates all possible
curl examples directly.
A follow-up commit is needed to modify the templates
accordingly.
As a goal of moving towards a common template,
we need to fetch curl examples' configurations
directly from openapi data instead of having them
hardcoded in templates. This commit introduces
x-curl-examples-parameters to store the configs
for the same.
* Have the `get_active_presence_idle_user_ids` function look at all the
user data, not just `private_message` and `mentioned`.
* Fix a couple of incorrect `missedmessage_hook` tests, which did not
catch the earlier behaviour.
* Add some comments to the tests for this function for clarity.
* Add a helper to create `UserMessageNotificationsData` objects from the
user ID lists. This will later help us deduplicate code in the event_queue
logic.
This fixes a bug which earlier existed, that if a user turned on stream
notifications, and received a message in that stream which did not mention
them, they wouldn't be in the `presence_idle_users` list, and hence would
never get notifications for that message.
Note that, after this commit, users might still not get notifications in
the above scenarios in some cases, because the downstream logic in the
notification queue consumers sometimes erroneously skips sending
notifications for stream messages.
Since `flags` here could be iterated through multiple times
(to check for push/email notifiability), we use `Collection`.
Inspired by 871e73ab8f.
The other change here in the `event_queue` code is prep for using
the `UserMessageNotificationsData` class there.
We will later consistently use these functions to check for notifiable
messages in the message send and event_queue code.
We have these functions accept the `sender_id` so that we can avoid the
`private_message = message["type"] == "private" and user_id != sender_id`
wizardy.
Before this commit, we used to pre-calculate flags for user data and send
it to Tornado, like so:
```
{
"id": 10,
"flags": ["mentioned"],
"mentioned": true,
"online_push_enabled": false,
"stream_push_notify": false,
"stream_email_notify": false,
"wildcard_mention_notify": false,
"sender_is_muted": false,
}
```
This has the benefit of simplifying the logic in the event_queue code a bit.
However, because we sent such an object for each user receiving the event,
the string keys (like "stream_email_notify") get duplicated in the JSON
blob that is sent to Tornado.
For 1000 users, this data may take up upto ~190KB of space, which can
cause performance degradation in large organisations.
Hence, as an alternative, we send just the list of user_ids fitting
each notification criteria, and then calculate the flags in Tornado.
This brings down the space to ~60KB for 1000 users.
This commit reverts parts of following commits:
- 2179275
- 40cd6b5
We will in the future, add helpers to create `UserMessageNotificationsData`
objects from these lists, so as to avoid code duplication.
This is separate from the next commit for ease of testing.
To verify that the compatibility code works correctly, all message send
and event_queue tests from our test suite should pass on just this commit.
Moved the `delete_message` user-confirmation modal to
the `confirm_dialog` folder and renamed the modal to `confirm_delete_message.hbs`
to follow the common naming convention.
Moved `revoke_invite` user-confirmation modal to the
`confirm_dialog` folder and renamed the modal to
`confirm_revoke_invite.hbs` to follow the common naming convention.
Moved `resend_invite` user-confirmation modal to the
`confirm_dialog` folder and renamed the modal to
to `confirm_resend_invite.hbs` to follow the common naming convention.
Moved `emoji_settings_warning` modal to the `confirm_dialog`
folder and renamed the modal to `confirm_emoji_settings_warning.hbs`
to follow the common naming convention.
Moved `deactivation_user` modal to the `confirm_dialog`
folder within `/static/templates` and renamed the modal to
to `confirm_deactivate_user.hbs` to follow the
common naming convention.
Moved `deactivation_stream` user-confirmation modal to
the `confirm_dialog` folder and renamed the modal to
`confirm_deactivate_stream.hbs` to follow the common naming convention.
Moved `deactivate_realm` modal to the `confirm_dialog` folder
within `/static/templates` and renamed the modal to
`confirm_deactivate_realm.hbs` to follow the naming convention.
Moved `delete_topic` modal to `confirm_dialog` folder and
renamed the modal to `confirm_delete_topic.hbs`
to follow the confirm_dialog naming conventions.
Moved `subscription_invites_warning` modal to `confirm_dialog`
folder and renamed the modal to `confirm_subscription_invites_warning.hbs`
to follow the naming convention.
Moved `unsubscribe_private_stream` modal to the newly created
`confirm_dialog` folder found within `static/templates`.
Later renamed the modal to `confirm_unsubscribe_private_stream.hbs`
to follow a common naming convention.
The user deactivate button is also present in the "Deactivated users"
tab, a sibling element of the current modal_parent, #admin-user-list.
Adding the confirm_dialog modal to #admin-user-list won't have any
effect in the "Deactivated users" tab.
Move it one level up, i.e. to the parent element of #admin-user-list
and #admin-deactivated-users-list.
Fixes#18928.
We now encode resolved topics with just:
U+2714 HEAVY CHECK MARK, SPACE
Previously, the encoding was unintentionally this:
U+2714 HEAVY CHECK MARK, U+FE0F VARIATION SELECTOR-16, SPACE
There are several benefits of using tippyjs here:
* Removes dependency on bootstrap.
* We don't have to manually handle show/hide of popover.
* There cannot be any memory leak since we don't store
the instance.
Since the instance.popper can return same elements as the
instance may be used again by tippy, we use `one` to ensure
that we do not define multiple event handlers for the same element
repeatedly.
This fixes the following bug:
* Open the streams modal.
* Click and hold in the word "Streams" at the top.
* Move pointer up out of the modal.
* Release.
* Expected: Some text is selected, but nothing else happens.
* Actual: The modal disappears.
We use the same fix we use for this class of issue in other places:
checking for whether a range is selected, and if so, doing nothing.
We previously had a mix of "Filter users" and "Search people" for this
widget. "Search" is more correct because the right sidebar can only
show a subset of the organization in some settings.
Earlier, when a user clicked on any stream name from the
user_popover, the stream page would open in the background,
but the user popover wouldn't close.
Fixed it by explicitly binding it to a click handler,
which closes the user popover before redirecting to stream
page.
Suyash Vardhan Mathur
Abhijeet Prasad Bodas
aryanshridhar
Ganesh Pawar
Gaurav Pandey
Priyank Patel
Aman Agrawal
Dinesh
Tim Abbott