When there are only muted unread mentions in a stream, show `@` icon
and unread count in faded style, also align the `@` on more topics
with no unead counter on it.
If there are only muted unread messages without mentions don't show
the unread counter on the stream.
Fixes#25382.
The "Mark as unread" event handler was not passing through the
mentioned_me_directly value, which is now important to left sidebar
rendering.
See the extended comment for how this solution is incorrect/incomplete
and has to fall back to guessing a potentially incorrect value in rare
situations.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
This is how other overlays are managed, and will be important in
upcoming refactoring, since we don't want the overlay height to be
restricted by the height of the `.app`.
We need to append the `version` parameter when constructing the urls for
medium-sized images so that the browser updates the image in real time when
the user uploads a new avatar.
Fixes#25558.
This commit updates the Help Center links in all relevant empty message
list views to open in a new tab by default. This prevents users from being
navigated away from the app.
Fixes#25337.
The use of named areas with `grid-area` make it unnecessary to
declare `grid-row` or `grid-column` values. (Note also that
grid areas must not be presented in quotation marks.)
Additionally, because `.unread_marker` is no longer placed on the
grid by itself (i.e., it always accompanies `.date_unread_marker`
or `.message_unread_marker`), it does not need any manual grid
placement, `grid-area` or otherwise.
This change enables the unread marker to participate as a grid item,
rather than the product of various absolute/relative positioning
hacks. The intention is to therefore prevent the blue active-message
box from disappearing on browsers that have zoomed out (~80% zoom).
With grid in place, this also makes for a more robust presentation
of each message row, and named grid areas should make it possible to
modify and extend the grid into the future.
Finally, this change removes styles that are no longer necessary in
the context of CSS Grid.
Adds examples of the regex pattern and old URL string format to
the deprecated `realm_filters` event and register response field.
The examples are in the prose description since the events are
no longer sent and therefore no longer tested.
Revises API changelog entry for missing endpoint method and to
clarify the overall text.
Updates Changes notes for feature level 176 to not have repetitive
text, so that the updates were clearer and more concise.
The original commit with the changes related to this API changelog
entry is commit 268f858f39.
This commit updates the API to check the permission to subscribe other
users while inviting. The API will error if the user passes the
"stream_ids" parameter (even when it contains only default streams)
and the calling user does not having permission to subscribe others to
streams.
For users who do not have permission to subscribe others, the
invitee will be subscribed to default streams at the time of
accepting the invite.
There is no change for multiuse invites, since only admins are allowed
to send them, and admins always have the permission to subscribe
others to streams.
Since 74dd21c8fa in Zulip Server 2.1.0, if:
- ZulipLDAPAuthBackend and an external authentication backend (any aside
of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones
enabled in AUTHENTICATION_BACKENDS in /etc/zulip/settings.py
- The organization permissions don't require invitations to join
...then an attacker can create a new account in the organization with
an arbitrary email address in their control that's not in the
organization's LDAP directory.
The impact is limited to installations which have the specific
combination of authentication backends described above, in addition to
having the "Invitations are required for joining this organization
organization" permission disabled.
This argument was added with the default incorrectly set to `True` in
bb0eb76bf3 - despite
`maybe_send_to_registration` only ever being called in production code
in a single place, with `password_required=False` explicitly. And then
it just got carried forward through refactors.
`maybe_send_to_registration` was/is also called twice in tests, falling
back to the default, but the `password_required` value is irrelevant to
the tests - and if anything letting it use the `True` has been wrong,
due to not matching how this function is actually used.
Added styling to show no outline around the copy to clipboard button on click.
Previously, when clicking this button, a rectangular outline appeared around
the button, which didn't look good, since a 'Copied!' message was already displayed.
Fixes#25533.
This adds a CSS stylelint rule that will catch erroneous quotation
marks around named grid-areas, which should be <custom-ident> values,
not strings.
So, for example, `grid-area: "my_area";` is an error. It should be
`grid-area: my_area;`.
This prevents `get_user_profile_by_api_key` from doing a sequential
scan.
Doing this requires moving the generation of initial api_key values
into the column definition, so that even bare calls to
`UserProfile.objects.create` (e.g. from tests) call appropriately
generate a random initial value.
Adds an API changelog note to 2.1 for the addition of
realm_default_external_accounts to the `/register-queue` response.
Also adds a Changes note to the field in the endpoint's response
API documentation.
The original commit that added it to that endpoint's response was
commit d7ee2aced1.
This commit fixes a typo in the selector used to
validate registration, support, realm creation,
password reset and terms of service forms. This
typo also resulted in a bug where "This field is
required" error message was shown at incorrect
position and this change fixes it.
This commit also fixes the client side error
handling of these forms which did not work
perfectly due to the selector being wrong.
If the spectator registration call fails, properly log the error and
call `reject` with an error object, not the xhr that `channel.post`
calls its error callback with.
This does nothing to address the UI question of what to do should this
request fail.
The default for Javascript reporting is that Sentry sets the IP
address of the user to the IP address that the report was observed to
come from[^1]. Since all reports come through the Zulip server, this
results in all reports being "from" one IP address, thus undercounting
the number of affected unauthenticated users, and making it difficult
to correlate Sentry reports with server logs.
Consume the Sentry Envelope format[^2] to inject the submitting
client's observed IP address, when possible. This ensures that Sentry
reports contain the same IP address that Zulip's server logs do.
[^1]: https://docs.sentry.io/platforms/python/guides/logging/enriching-events/identify-user/
[^2]: https://develop.sentry.dev/sdk/envelopes/
Django 4.0 and higher began checking the `Origin` header, which made
it important that Zulip know accurately if the request came over HTTPS
or HTTP; failure to do so would result in "CSRF verification failed"
errors.
For Zulip servers which are accessed via proxies, this means that
`X-Fowarded-Proto` must be set accurately. Adjust the documentation
for the suggested configurations to add the header.
Fixes: #24599.
Co-authored-by: Alex Vandiver <alexmv@zulip.com>
These changes ensure that only headings targeted by URL fragments are
highlighted in full. Div elements will have their immediate first
child element highlighted instead (e.g., the first element of an API
parameter box).
1c76036c61 raised the number of `minfds` in Supervisor from 40k to
1M. If Supervisor cannot guarantee that number of available file
descriptors, it will fail to start; `/etc/security/limits.conf` was
hence adjusted upwards as well. However, on some virtualized
environments, including Proxmox LXC, setting
`/etc/security/limits.conf` may not be enough to raise the
system-level limits. This causes `supervisord` with the larger
`minfds` to fail to start.
The limit of 1000000 was chosen to be arbitrarily high, assuming it
came without cost; it is not expected to ever be reached on any
deployment. 262b19346e already lowered one aspect of that
changeset, upon determining it did come with a cost. Potentially
breaking virtualized deployments during upgrade is another cost of
that change.
Lower the `minfds` it back down to 40k, partially reverting
1c76036c61, but allow adjusting it upwards for extremely large
deployments. We do not expect any except the largest deployments to
ever hit the 40k limit, and a frictionless deployment for the
vanishingly small number of huge deployments is not worth the
potential upgrade hiccups for the much more frequent smaller
deployments.
- Renames page title to "Restrict stream membership management".
- Renames section about "Who can add users to streams" setting.
- Adds new section "Configure who can remove users".
- Updates help/stream-permissions
Fixes#25264.
Updates the descriptions and examples for there only being two key
values: "website" and "aggregated".
Also, clarifies that email keys are the Zulip display email.
And removes any descriptive text that says presence objects have
information about the clients the user is logged into.
Deleting a message can race with sending a push notification for it.
b47535d8bb handled the case where the Message row has gone away --
but in such cases, it is also possible for `access_message` to
succeed, but for the save of `user_message.flags` to fail, because the
UserMessage row has been deleted by then.
Take a lock on the Message row over the accesses of, and updates to,
the relevant UserMessage row. This guarantees that the
message's (non-)existence is consistent across that transaction.
Partial fix for #16502.