Since validators do not affect the database, this migration is a noop.
Removing the migration fails check-database-compatibility. We might
eventually delete it when Django supports a cleaner method for deletion.
TODO:
Remove the type annotation when django-stubs is integrated.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Doing the dispatch to authenticated_json_view first lets us avoid
messing around with the skip_rate_limiting parameter.
Since rate_limit itself checks user.is_authenticated, there's no
potential downside to doing that check first here.
This refactoring is necessary to separate the expected type annotation
for view functions with different authentication methods. Currently the
signature aren't actually check against view functions because
`rest_path` does not support type checking parameter types, but it will
become useful once we do.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
`authenticated_rest_api_view` and `authenticated_json_view` essentially
remove `UserProfile` from the decorated function.
Note that `authenticated_log_and_execute_json` is removed to avoid
duplicating `ParamT` unnecessarily in the helper.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This refactors rate limit related functions from `zerver.decorator` to
zerver.lib.rate_limiter.
We conditionally import `RemoteZulipServer`, `RequestNotes`, and
`RateLimitedRemoteZulipServer` to avoid circular dependency.
Most instances of importing these functions from `zerver.decorator` got
updated, with a few exceptions in `zerver.tests.test_decorators`, where
we do want to mock the rate limiting functions imported in
`zerver.decorator`. The same goes with the mocking example in the
"testing-with-django" documentation.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This refactors `rate_limit` so that we no longer use it as a decorator.
This is a workaround to https://github.com/python/mypy/issues/12909 as
`rate_limit` previous expects different parameters than its callers.
Our approach to test logging handlers also needs to be updated because
the view function is not decorated by `rate_limit`.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
When the user added space/s right after the topic typehead symbol `>`,
a thin blue line would be selected at the top of the typeahead menu.
To avoid this and to make stream and topic typeaheads' behaviour more
consistent with each other, space/s right after `>` is not allowed,
like it is not allowed right after `#`.
Fixes: #19124.
This commit is a preparatory commit for #20870, it introduces
`handle_narrow_deactivated` and `handle_narrow_activated`
functions in pm_list.js, separately from top_left_corner.js,
to reduce the complexity of handling private messages section
separately.
Adds an API endpoint for accessing read receipts for other users, as
well as a modal UI for displaying that information.
Enables the previously merged privacy settings UI for managing whether
a user makes read receipts data available to other users.
Documentation is pending, and we'll likely want to link to the
documentation with help_settings_link once it is complete.
Fixes#3618.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Previously, our modal system prevented opening a modal when one was
already open. It appears this was implemented to work around the fact
that we're using Micromodal selectors to determine if a modal is open
(and those don't update until after an animation frame).
We'd like to support opening the full user profile and manage user
modals while read receipts is open. While we could work around this in
that place, it feels like one needs a lot of documentation in order to
add a setTimeout in those code paths.
So we instead make open_modal support this, with a guard to prevent
infinite recursion in case of future bugs.
Note that dialog_widget was already closing modals before opening the
next one, so this is a behavior change only for our 3 modals that do
not use dialog_widget.
(I'm not sure why the `dialog_widget` modals did not already require a
delay, but likely there's some CSS difference).
We likely will want to redo this to instead use a better state
tracking system.
See https://chat.zulip.org/#narrow/stream/49-development-help/topic/close.20and.20open.20another.20modal.20immediately
for discussion.
The previous version with e.target would give the element that was
clicked lying inside an element with '.view_user_profile'.
One would usually expect "data-user-id" to be attached to the
same element with ".view_user_profile" instead of any of its children.
So, to just look for "data-user-id" in the element with that class,
instead of any of its chidren, this commit changes e.target to
e.currentTarget.
We show tooltip for user read receipts setting mentioning
that the organization has disabled read receipts setting
when an organization does so. We hide the tooltip when
organization read receipts setting is enabled.
We also fix the alignment of "i" icons with label and headings
at various places by moving it 1 pixel below. There may be
some places where it is not fixed, but those will be fixed
separately.
This commit adds support to change enable_read_receipts
setting through API and also adds the field to response
of "/register" endpoint so that the setting value
is available to clients.
This reverts commit 46b289cbda.
This commit didn’t pass Node tests independently of the PR #21726 that
it was split from, because pm_list is mocked.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is a preparatory commit which introduces
`handle_narrow_deactivated` and `handle_narrow_activated`
functions in pm_list.js, separately from top_left_corner.js,
to reduce the complexity of handling private messages section
separately.
The text inside save/discard widget buttons was misaligned with
respect to the icon in the button. To align it properly, we add
vertical-align and a reduced line-height property to the span.
Fixes: #20583.
Resolves the issue by aligning the buttons with the text.
It's not entirely clear why text-bottom is the correct alignment, but
visually it seems to be correct.
Fixes: #20583.
This code is actually a noop (and would be a bug if it wasn't a noop),
because when this runs the server is already initialized, meaning the
internal realm exists and the system bots have been created, so
UserProfile.objects.filter(email=email) is always truthy. Also, system
bots are supposed to live in the internal realm, not in the realm being
imported so this code doesn't make sense currently.
This ensures type safety by not mutating the original queryset values,
that django-stubs to type as a TypedDict without total=False.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
BACKEND_DATABASE_TEMPLATE was introduced in a507a47778.
This setting is only available for the test cases and it is not that
necessary to have it configurable.
We define it as a global variable in zerver.lib.test_fixtures.
This avoids requiring mypy_django_plugin to know the type of
settings.BACKEND_DATABASE_TEMPLATE for type checking purposes, given the fact
that settings.test_extra_settings is not available in production/development
setup.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This ensures that CAMO_KEY is always defined, so that mypy_django_plugin
will be able to identify its type.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
We now use EVERYONE_GROUP_NAME instead of writing
the actual group name at multiple places, so that we
can have all the group names coded at one place only.
We now use MEMBERS_GROUP_NAME instead of writing
the actual group name at multiple places, so that we
can have all the group names coded at one place only.
We now use MODERATORS_GROUP_NAME instead of writing
the actual group name at multiple places, so that we
can have all the group names coded at one place only.
We now use ADMINISTRATORS_GROUP_NAME instead of writing
the actual group name at multiple places, so that we can
have all the group names coded at one place only.
We now use OWNERS_GROUP_NAME instead of writing
the actual group name at multiple places, so that
we can have all the group names coded at one place
only.
We now use EVERYONE_ON_INTERNET_GROUP_NAME instead of
writing the actual group name at multiple places, so
that we can have all the group names coded at one place
only.
We now use FULL_MEMBERS_GROUP_NAME instead of
writing the actual full members system group
name at multiple places, so that we can have
all the group names coded at one place only.
There may be some internal realms which were created after applying
"0382_create_role_based_system_groups.py" migration and this migration
is used to create system groups for those realms.
This commit modifies bulk_create_users to add the users to the
respective system groups. And due to this change, now bots in
development environment are also added to system groups.
Tests are changed accordingly as more UserGroupMembeship objects
are created.
Since we include internal realms while creating system groups
in "0382_create_role_based_system_groups.py", we should do it
when creating new internal realms as well to be consistent.
Tests are changed accordingly as UserGroup objects are created.
We also change the user group ids used in api docs examples
such that user groups are of correct realm.
This includes the change from 28fde2ee27.
Only a minor bump is required because it has no effect on type
checking yet before django-stubs gets integrated.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
It was introduced in
56b2b838ee commit.
It fixes `test_narrow_public_streams` test which checks
that, there are no bookends in ` /streams/public`. The
issue was there were no bookends by default when we
were checking in the Denmark stream. We fix this by
unsubscribing from the Denmark stream which will
create a bookend.
I found the previous model for computing what settings to use for
streams increasingly difficult to understand, which is generally a
recipe for future bugs.
Refactor to have a clear computation of what complete permissions
state the client is requesting, validate that state, and then pass
that state to the do_change_stream_permission.
We now allow changing access to history of the stream by only passing
"history_public_to_subscribers" parameter. Previously, "is_private"
parameter was also required to change history_public_to_subscribers
otherwise the request was silently ignored.
We also raise error when only history_public_to_subscribers parameter
is passed with value False without "is_private: True" for a public
or web-public stream since we do not allow public streams with
protected history.
We raise error when we try to change a public stream (except for
zephyr mirror realms) to be public with protected history, as we do
not support such streams yet.
Previously, in such case we changed nothing and a notification was
sent to the "stream events" topic with message being "stream is
changed from public to public" and was weird.
Note that this commit only handles the case when both is_private and
history_public_to_subscribers parameters are passed to API and commit
not covers the case when only "history_public_to_subscribers" with
value False is passed to API, since we currently ignore requests
which has only history_public_to_subscribers parameter with not None
and not is_private and is_web_public.
We would do this in further commits when we add support for accepting
only history_public_to_subscribers parameter.
Zixuan James Li
Tim Abbott
N-Shar-ma
jai2201
Dinesh
Sahil Batra
Anders Kaseorg
evykassirer
Rishabh-792
Biki-das
Mateusz Mandera
Riken Shah