Previously, we included all three message edit related settings
("allow_message_editing", "message_content_edit_limit_seconds" and
"edit_topic_policy") in the event data and api response irrespective
of which of these settings were changed. Now, we only include changed
settings and separate events are sent for each setting if more than
one of them is changed.
Note that the previous typed in event_schema.py for
`message_content_edit_limit_seconds` incorrectly did not allow `None`
as a value, which is used to encode no limit.
Recipient with type PERSONAL type_id 1 is a Recipient for a system bot,
since those get created first. Even if it doesn't break tests, it's
still bad, because it is not the intention of those tests to simulate a
cross-realm private message to a system bot.
Just using values 1 and 2 as stream ids is not good, because there's no
idea in which realm these streams are (or hypothetically if they exist).
This can create weird Messages with sender being a user of "zulip" realm
and the stream being in another realm - which would be a corrupted
state.
This refactors and renames user_ids_muting_topic to accept a parameter
'visibility_policy' and fetch user IDs that have a specific
visibility_policy(provided as the parameter) set for a topic.
Unfortunately, doing so requires forking common API documentation
text, since we're not making any changes to other endpoints that don't
allow unauthenticated requests at all.
Follow-up on #21995.
build_message has a lot of arguments, so it's hard to verify correctness
of callers that just try to get the order right. It's much clearer to be
explicit via kwargs. mattermost.py and rocketchat.py already do this, so
let's bring slack.py and gitter.py up to par.
As mentioned in the TODO this commit deletes, the export with member
consent system was failing to account for the fact that if consenting
users only have access to a subset of messages of a stream with
protected history, only that subset should be exported - rather than all
the stream's messages.
Makes the footer content on doc pages more contextually appropriate
for self-hosted organizations, when `settings.CORPORATE_ENABLED` is
false.
When `settings.CORPORATE_ENABLED` is true, there is specific footer
content for the policy documentation pages, and for the help center
and API documentation pages.
Fixes#23068.
This label is unnecessary and creates the potential for an incorrect
assumption that it's only useful for testing, when in fact it's a
reasonable configuration overall.
There are cases where we add some text in italics inside parens along
with the label in checkbox settings.
This commit adds option to settings_checkbox template so that we can
directly use it and not require to duplicate the settings_checkbox
code and thus we now use settings_checkbox template for
enable_read_receipts setting.
Small follow-up to d86e4ac34d.
get_ makes it sound like it doesn't have side-effects, when these are
actually much like the django ORM .get_or_create function.
This is a type-unsafe workaround before we can fix the problem that
django_scim2 relies on request.user being present to authenticate
requests.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This breaks an import cycle that prevented django-stubs from inferring
types for django.conf.settings.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This breaks an import cycle that prevented django-stubs from inferring
types for django.conf.settings.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This breaks an import cycle that prevented django-stubs from inferring
types for django.conf.settings.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This breaks an import cycle that prevented django-stubs from inferring
types for django.conf.settings.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This breaks an import cycle that prevented django-stubs from inferring
types for django.conf.settings.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Removes a click handler in `populate_messages_sent_by_client` for
anchor links that start with a hash.
I think this goes back to when there was a sidebar navigation on
the stats page, which no longer exists. The only anchor link in
the current html is to the help center documentation and not part
of the Plotly charts.
Fixes “E713 Test for membership should be `not in`” found by ruff (now
that I’ve fixed it not to ignore scripts lacking a .py extension).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
For some reason, the CSS declared a different background color for this element
only with a narrow window media CSS query. Change this color to the default
background for the rest of this modal.
Fixes#22991.
SCIMClient is a type-unsafe workaround for django-scim2’s conflation
of SCIM users with Django users. Given that a SCIMClient is not a
UserProfile, it might as well not be a model at all, since it’s only
used to satisfy django-scim2’s request.user.is_authenticated queries.
This doesn’t solve the type safety issue with assigning a SCIMClient
to request.user, nor the performance issue with running the SCIM
middleware on non-SCIM requests. But it reduces the risk of potential
consequences worse than crashing, since there’s no longer a
request.user.id for Django to confuse with the ID of an actual
UserProfile.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
I found a highly reproducible bug using the "Mark as unread" feature,
which triggers a rerender via message_list.rerender_view().
The reproducer was as follows:
* Navigate to a narrow by going to All messages and using the `S` hotkey.
* Mark as unread to mark several messages as unread in that view.
* Notice that the message that had been selected in home_message_list
is immediately marked as read again.
What was happening is that the reselect_selected_id call for
message_lists.home (All messages) was incorrectly re-marking the
currently selected message as read, even though (1) that view was not
visible and (2) this was an internal rendering change that could not
be the first time the message was selected.
Because only the current message_list has marking messages as read
blocked, it's still able to mark the currently selected message as
read.
All the callers of reselect_selected_id are internal rendering code
paths that are not intended to be user-visible; as a result, they
should not change the unread state either.
The bug fixed here is a potential root cause of #16986, but I haven't
had a chacne to confirm it.
redo_selection and reselect_selected_id did the same thing: Reselect
the currently selected message as a result of internal rendering. I
combine the useful features of both -- not crashing if no message is
selected (id -1) and passing the `from_rendering` option, to avoid
potentially triggering an additional rerender.
We now first convert the element value to number using "Number()"
function and then call parseFloat in parse_time_limit function.
If we do not do so and the input element contains something like
"24a", it will be converted to 24 after parseFloat and will result
in an unexpected behavior where the save-discard widget will not
appear if the custom value input is changed from "24" to "24a",
since the value is considered as same as before.
But now "24a" will return NaN and save-discard widget will
appear with save button disabled.
Previously, typing something like "24aa" in message edit limit
custom input box would not disable the "Save changes" button
and clicking on it would set the limit to 24 minutes because
"24aa" was parsed to 24 by parseInt which is a valid value.
We now fix this to first convert the input to number using
"Number()" function and then use parseInt. "Number()" function
returns NaN for input like "24a" and other inputs containing
alphabet characters and thus it is considered as invalid value
and "Save changes" button is disabled.
Previously realm-level default of email notification batching period
setting was handled as a special case in populate_data_for_request.
But now we have added some functions to handle time limit settings and
this commit changes the email notification batching setting to be
handled similarly.
This commit renames get_message_edit_or_delete_limit_setting_value
function to get_time_limit_setting_value, so that we can use the
same function to get value for email notification batching setting
value.
Since set_msg_edit_limit_dropdown and set_msg_delete_limit_dropdown
have almost same code except the ID of elements, we extract a common
function set_time_limit_setting and both the above functions call
this new function only.
We can use this function for topic edit limit setting which will be
added in further commits.
We now show save-discard widget on changing the message edit and delete
limit setting dropdown from any value to "Custom" only after value inside
the custom input is changed. This makes sense as the setting value is
not actually changed unless the custom input is not changed and also
makes the behavior consistent with realm-level default of notification
batching period setting.
After this change, the dropdown element and custom input element are not
considered as different setting elements for code purposes and are
treated as single setting like the realm-level default of notification
batching period setting. And thus we remove the prop-element class
from the custom input elements of these settings.
This commit extracts a function to show or hide the custom
input of message edit and delete limit setting and to set
the initial value of custom input while showing it.
This commit changes time_limit_dropdown_values from map to
list like we have email_notifications_batching_period_values.
This change will help us in further commits for refactoring
the message edit and delete settings related code.
We change the id and name of message delete limit dropdown to
"id_realm_message_content_delete_limit_seconds" and
"realm_message_content_delete_limit_seconds" respectively.
This is a prep commit for sending only changed settings in
message editing section to the API.
We change the id and name of message edit limit dropdown to
"id_realm_message_content_edit_limit_seconds" and
"realm_message_content_edit_limit_seconds" respectively.
This is a prep commit for sending only changed settings in
message editing section to the API.
The implementation is simple, we just check if the
the message sender is a notification bot to decide if we
should show the read receipts list.
We also update the modal content styling to match the padding at the
top of the modal.
Fixes#22905
Since Django factors request.is_secure() into its CSRF check, we need
this to tell it to consider requests forwarded from nginx to Tornado
as secure.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Alya Abbott
Sahil Batra
Mateusz Mandera
Kartik Srivastava
Anders Kaseorg
Aman Agrawal
Matt Keller
Lauryn Menard
Tim Abbott
Zixuan James Li
evykassirer
Taiki
Steve Howell
Riken Shah