While uploading a file, if you close the compose box, and reopen
it, compose send button remains disabled due to upload in progress
being true.
To fix it, we update upload status for compose when upload is
cancelled.
This reverts commit 7d08f32ebb.
The commit message is factually incorrect, and the change broke our
fade-out transitions. visibility can be transitioned, and there is a
specific rule for what that means. This is critical for transitioning
opacity in the fade-out direction: if you fail to also transition
visibility, then the element disappears immediately regardless of
opacity.
https://developer.mozilla.org/en-US/docs/Web/CSS/visibility#interpolation
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This code was originally added in 608173657d in Zulip Server 2.0;
since we can only directly upgrade from 5.0 or later, this code is
guaranteed to have run already. Remove it.
This code was originally added in 5f3765b872 in Zulip Server 4.0;
since we can only directly upgrade from 5.0 or later, this code is
guaranteed to have run already. Remove it.
This code was originally added in 2b146012e1 in Zulip Server 1.7.0;
since we can only directly upgrade from 5.0 or later, this code is
guaranteed to have run already. Remove it.
The python3-yaml dependency was added at install time in 3314fefaec
in Zulip Server 4.0, and this workaround was added in de41a10d38,
also in 4.0. Since we can only directly upgrade from 5.0 or later,
the dependency is guaranteed to be installed already, by one or the
other of those ways. Remove this workaround.
This code was originally added in 382261dc72 in Zulip Server 3.0;
since we can only directly upgrade from 5.0 or later, this code is
guaranteed to have run already. Remove it.
This code was originally added in e705883857 in Zulip Server 5.0;
since we can only directly upgrade from 5.0 or later, this code is
guaranteed to have run already. Remove it.
`visibility` cannot be animated since it is a boolean.
This fixes composition failure error in Chrome dev tools when
these animations are triggered that the animation has
no visible change.
We're doing this so that the client can keep track of which channels
it might need to request full subscriber data from, and which already
have full subscriber data.
When hovering over the user avatar, the tooltip
"View user card" appears. If this tooltip appears
over the currently selected message, then pressing
`u` once doesn't show the user card popover, rather
it only hides the tooltip. It is on the second press of `u`
that the user card appears.
This commit fixes that.
We also add some comments to help clarify this code path.
Fixes#32970
When navigating from a short message to a tall message via up
keypress, we used to jump to the top of the message. This
doesn't align with user's expectation that up / down keypress
will let them see the entire message feed.
To fix it, we can `page_up` which scrolls up the correct amount
and then our message selection logic kicks in to select the
correct message on screen.
This prevents a thundering herd for videos -- if a very large video is
posted to a channel with many active clients, all of them
simultaneously request it, to provide the in-feed preview image.
While these requests come with a `Range` header which is intended to
limit the request to just the first couple MB, nginx ignores this
header when making its request to the upstream -- so it can obtain and
cache the whole file locally. This results in multiple competing
requests for the whole content from S3, all racing to store the
content in the cache.
Use cache slicing to split the content cache into chunks of 5MB; the
cache is filled one slice at a time, as needed based on the byte
ranges that clients request. Clients making requests without a
`Range` header are provided with the content transparently stitched
together from the individual slices.
The slice size of 5MB is chosen to encompass more 95% of file
uploads (saving an extra trip to the origin) while also being large
enough to be able to provide video thumbnails in a single slice, as
well as not take too much time to obtain from the upstream.
The `$host` nginx variable is _not_ the unadulterated `Host`
header (which would be `$http_host`) -- it is that header, *without
the port*, with a fallback to the `server_name` which processed the
request.
This means that backend services are not aware of the port that the
request came in on, unless they derive that from reading
`nginx_listen_port` in `/etc/zulip/zulip.conf`, or similar.
Specifically, this caused `tusd`, on deploys with non-standard
`nginx_listen_port`, to generate a `Location` header which left off
the port, and as such attempted a CORS check when retrieving metadata
about the just-uploaded file, which failed.
Add the port to the `Host` header we pass to `tusd` and other backend
services.
In deploys `nginx_listen_port` set, tusd would fail to send its hook
requests, as it assumed that nginx would always be listening on
127.0.0.1:80.
Set the `nginx_listen_port` on the hook URL, if necessary.
This makes the `localhost.d` directory less of a lie, and decreases
the chances that local reconfigurations will break the 127.0.0.1:80
server which is used for IPC.
In cases where `nginx_http_only` is enabled, we respect
`nginx_listen_port` soas to not attempt to bind on port 80 if the
administrator was explicitly attempting to avoid that.
When adding new messages, we were updating buddy list which
resulted in insertion errors.
Fixed by not updating the right sidebar in case of spectators.
Fixes CI - it was failing due to the API test for organization exports,
which was returning an error due to there being no Organization Owners
with consent to private data export.
As explained in the comments, if in an export with consent there are no
consenting owners or in a public export there are no owners with email
visibility set to at least ADMINS, the exported data will, upon import,
create an organization without usable owner accounts.
Adds detailed tests for the work in the prior commits fixing the
treatment of private data in various tables in exports with consent and
public exports.
This is private information, as by inspecting the DirectMessageGroup
objects and their associated Subscription objects, you could determine
which users conversed with each other in a DM group.
This did *not* leak any actual message - only the fact that at least one
of the users in the group sent a group DM.
The prior significantly restricted what data gets exported from
non-consented users. The last thing we're missing is to fix the logic
to work correctly for public exports.
Prior commits focused on addressing exports with consent. This commit
adapts it to work with public exports.:
- Do not turn user accounts into mirror dummies in the public export - or
after export->import you'll end up with a realm with no functional
accounts; as every user is non-consented and the original logic added in
the prior commits will turn them into mirror dummies.
- Some of the custom fetch/process functions were changed without
considering public exports - now they work correctly, by setting
consenting_user_ids to an empty set.
The Subscription Config is constructed in a bit of a strange way, that's
not compatible with defining a custom_fetch function.
Instead we have to extend the system to support passing a custom
function for processing just the final list of rows right before it's
returned for writing to export files.
As explained in the comment, if we turn a non-consented deactivated user
into a mirror dummy, this will violate the rule that a deactivated user
cannot restore their account by themselves after an export->import
cycle.
As explained in the comment added to the function, in terms of privacy
concerns, it is fine to export all data for these accounts. And it is
important to do - so that exporting an organization which was originally
imported e.g. from Slack doesn't result in excessively limited data for
accounts that were mirror dummies and never "activated" themselves.
