Lightbox previews for youtube playlists use the "current" video in the playlist
for the preview. The open link for such previews is incorrectly set to the first
video alone, and not the playlist. This commit fixes the bug by linking to the
original URL for lightbox preview is being shown, instead of computing the URL.
We're changing our style to always show the scrollbar on the right
pane of modals, because that makes it consistently clear when there
are more items below.
It's not clear why we added this (I didn't notice it in review), and
it seems to have been in error, since none of the previous CSS in
5c36918c17 applied to that overlay.
So reverting that hunk.
See #12435 for the original investigation.
This also means the default dev environment is now based on Ubuntu
18.04 (bionic), part of our overall effort to migrate off Ubuntu
Trusty.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Ubuntu 14.04 is EOL. Mac users can use the VirtualBox provider (and
now maybe the Docker provider?). We can add back the VMware Fusion
provider later if someone cares enough to get it working with Ubuntu
18.04.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
This is a key part of our process to deprecate Ubuntu trusty: migrating
the Zulip development environment on macOS and Window to Ubuntu
Bionic.
As part of this, we need to remove ubuntu-server, because it now
depends on update-notifier-common.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
The jedi package exec()s some code in the context of the fake module
blub, causing errors when generating the coverage report. See
https://github.com/davidhalter/jedi/issues/1122.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
An unnecessary log file gets generated when running vagrant up for the
first time with the Ubuntu Bionic box. This looks like it is being
caused upstream by the base box containing a Vagrantfile with a line
that looks something like:
vb.customize [ ..., ..., ..., ..., \
File.join(Dir.pwd, "ubuntu-bionic-18.04-cloudimg-console.log") ]
The line added here negates this.
Sometimes it's useful to run two copies of test-backend at the same
time. The problem with doing so is that we need to make sure no two
threads are using the same test database ID.
Previously, this worked only if at most one of those copies was
running in the single-threaded mode, because we used a random database
ID for the single-threaded code path, but the same IDs counting from 0
for the parallel code path.
Fix this, mostly, by generating a random start for the range of IDs
used by the process, and then counting off database IDs starting from
there (both in the parallel and non-paralllel modes).
There's still a very low probability race, see the TODO.
Additionally, there appear to be some other races with running two
copies of test-backend at the same time not related to the database.
See https://github.com/zulip/zulip/issues/12426 for a follow-up issue
that's sorta created by this.
The test-backend parallel test runner system doesn't actually use the
zulip_test database; instead, it creates its own databases off the
zulip_test_template database.
We were accidentally running `tools/generate_fixtures` even when there
are no changes, because this function is shared with the
tools/lib/test_server.py codebase, which needs us to do the work of
creating a test database for it off the zulip_test_template database.
Fixing this saves about 1.5s / 4s of the runtime of a single test.
Previously, if you exported a Zulip organization and then re-imported
it, we'd end up renumbering the user IDs and all direct foreign key
references to them in the database, but not the data-user-id
references in mentions. Fix this by parsing the message content and
doing that renumbering.
(Because we import raw markdown, not HTML, from third-party tools,
these changes won't affect data import from slack etc.)
Fixes the high-priority part of #11293.
Modifies the dict with the user info to include the key `bot_owner_id`
so it can be displayed in the user info popover.
Tests concerned with changing bot owner have been modified to have
number of events=2 because while updating the bot info, two events
are fired -- updating the `realm_bot` and `realm_user` since the
key `bot_owner_id` is a part of realm user info.
Since positional arguments are interpreted differently by different
backends in Django's authentication backend system, it’s safer to
disallow them.
This had been the motivation for previously declaring the parameters
with default values when we were on Python 2, but that was not super
effective because Python has no rule against positional default
arguments and that convention for our authentication backends was
solely enforced by code review.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
Anders Kaseorg
Vishnu Ks
Puneeth Chaganti
Tim Abbott
Aman Agrawal
Priyank Patel
Rishi Gupta
Mateusz Mandera
Anders Kaseorg
Wyatt Hoodes
Eeshan Garg
Vaibhav