We incorrectly include many realm settings in the data section of
'realm/update_dict' schema. It should only contain the settings
related to message edit, realm icon, realm logo and authentication
methods and not other settings, becausea all the other settings send
'realm/update' event and not 'realm/update_dict' event.
This commit only removes 'default_twenty_four_hour_time' and
'default_language', others will be removed separately.
Now, the markdown extension of curl_examples generates
all examples of all possible configurations with
their descriptions, and so we need to separate
executable curl commands from the rest of the raw
HTML.
This commit simply changes the indentation of the
block and replaces the command being tested
with each element of the commands array. This
was split for an easier review.
Now, the markdown extension of curl_examples generates
all examples of all possible configurations with
their descriptions, and so we need to separate
executable curl commands from the rest of the raw
HTML.
This commit adds a commands variable to store
all the curl commands in HTML using regex.
Now, include and exclude configuration
are fetched from openapi data, and only
one type can be encoded for every example.
This removes the need for the assertion to
test if both include and exclude are present
since at a time, only one can be present.
Now, all possible configurations for curl examples
are rendered directly from openapi data, and
the templates should just call the markdown
function once.
This commit adjusts all the templates by removing
hardcoded configurations and descriptions for
individual curl examples.
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.
sahil839
Suyash Vardhan Mathur
Abhijeet Prasad Bodas
aryanshridhar
Ganesh Pawar
Gaurav Pandey
Priyank Patel
Aman Agrawal
Dinesh
Tim Abbott