A few things here:
* Use _.each to follow our convention.
* Just use new locals to avoid overwriting template and
avoid strange Object.assign hack.
* Just use simple string concatenation.
* Use better var names: full_name, shortcut
* Use chaining syntax.
This logging was apparently broken when sorting imports; it's a fairly
unique thing in our codebase that this would be a problem. Prevent
future regressions by adding this exception explicitly to the isort
configuration.
Our recent addition of Content-Security-Policy to the file uploads
backend broke in-browser previews of PDFs.
The content-types change in the last commit fixed loading PDFs for
most users; but the result was ugly, because e.g. Chrome would put the
PDF previewer into a frame (so there were 2 left scrollbars).
There were two changes needed to fix this:
* Loading the style to use the plugin. We corrected this by adding
`style-src 'self' 'unsafe-inline';`
* Loading the plugin. Our CSP blocked loading the PDf viewer plugin.
To correct this, we add object-src 'self', and then limit the
plugin-type to just the one for application/pdf.
We verified this new CSP using https://csp-evaluator.withgoogle.com/
in addition to manual testing.
Previously, user-uploaded PDF files were not properly rendered by
browsers with the local uploads backend, because we weren't setting
the correct content-type.
This rule checks for use of const wherever needed, currently does
nothing since we don't use `let`, instead we use `var`. This rule
can be used to use refactor a file to use const easily by replaceing
var with let using a editor and then by running
`./node_modules/.bin/eslint frontend_tests --fix --cache`. And then revert
those `let`'s back to `var`.
These aren't perfect -- in particular "core chat experience" can
probably be broken up -- but I think they help in making a quick skim
work for getting some sense of what the changes are.
This change just reorders and adds headings, with virtually no wording
changes.
Caches in Circle are immutable -- even if a path in a cache changes in builds
after the cache was created, the cache is not updated if it already exists. This
was making the zulip-venv-cache and zulip-npm-cache directories useless on
Circle.
This commit changes the cache keys to depend on the checksums of the dependency
manifests (requirements/{dev,thumbor}.txt, package.json and yarn.lock). This
would ensure that the caches are updated when the environments change. It may
result in the occasional build being "uncached" -- when a dependency manifest
changes -- but builds without such changes will be much faster, and such builds
are a majority.
Previously, a code block with a small width would be displayed
inline with the previous paragraph's text.
To fix this, now every p inside an li element except the first is
a block instead of an inline-block. However, this only applies to
li elements for integration instructions.
This makes sense intuitively because if there are multiple p's
in a list element, not all of those should be inline-blocks. The
first one should be because it needs to be inline with the list
number. The rest should be treated (and displayed) as separate
paragraphs.
Another thing to keep in mind is that the way Markdown code
blocks get converted to HTML is such that every code block
becomes <p><code></code></p> when converted to HTML.
We let Markdown increment the list step numbers, which is more
reliable than keeping track of numbered-steps manually.
Also, instead of linking to the CircleCI docs, we now have full
instructions for how to setup a webhook by modifying the circle.yml
file.
Ancient GitLab from several years ago doesn't include the
HTTP_X_GITLAB_EVENT header (and seems to have a different format), so
we should ignore its requests.
Might be good to document the version threshhold, but it's very hard
to tell from Googling what it is.
The size information of an avatar is not required during the import.
Check function 'import_uploads_local' and 'import_uploads_s3'
in 'export.py' for this.
This is kind of easy to gloss over, especially with the framing
as a "format"; surely if things work at all, the file format
must have been right, right? It's really a bit more substantive
than that; say so and also add a bit more description.