Currently, whenever the database is changed from the default SQLite via
the DATABASE_URL environment variable, the connection to the database is
forced to be SSL. This is a great default for production use-cases.
However, in some scenarios, users may not want to use SSL, e.g. when
testing against a local MySQL or PostgreSQL database.
This change enables users to explicitly request a non-SSL connection to
the database by passing the `?sslmode=disable` (or similar) query
argument in the DATABASE_URL environment variable.
For backwards compatibility, if the `sslmode` is not set explicitly in
the connection URL, the code still defaults to requiring SSL on the
connection.
Currently most of doccano's Javascript is in webpack bundles, except for
a few snippets like swiper. To increase consistency, this change moves
the swiper code also into a webpack bundle.
In addition to increasing consistency, this also has the advantages of:
1) Giving developers a single location/directory to look for all the
Javascript.
2) Making the swiper dependency explicit by listing it in the
package.json manifest
3) Ensuring that swiper gets built and minified in the same way as other
dependencies.
4) Making swiper available when developing offline.
In the future, it would also be worth considering to move all the CSS
includes into webpack.
Currently if a superuser accesses any of the demo pages, the Django
server crashes with a NoReverseMatch as shown in the screenshot below:
This is caused by the fact that the demo pages re-use the annotation
base template. When the user is a superuser, the annotation base
template includes a link to edit the current project id. However, demo
projects don't have an id which causes the crash. This change fixes the
crash by only including the project edit link if the Django context
contains a project id.
Note that the linter acts on Vue components in both `.js` and `.vue`
files.
To keep the changes minimal and targeted, for now the linter uses a very
permissive rule-set which essentially means that the linter is mostly
disabled. As a separate change, we should fix all the lint issues and
tighten the rule-set to `plugin:vue/recommended`.
Currently Django and Vue are somewhat coupled in that the project
intermixes templating constructs from both eco-systems.
Examples of this in `projects.html` include:
- Checking if the user is a superuser to modify the Vue template.
- Using Django filters to inject the capitalized username.
This makes it somewhat hard to follow the Vue code and also makes it
more difficult to modularize the Vue components and re-use them.
As such, this change improves the separation of concerns by having the
Django template only scafold the root element for Vue and serialize any
variables that are required from the Django context to Javascript so
that Vue can access them. The rest of the templating is then moved into
a Vue single file component. This will make it easier for the developer
to understand the Vue components and make it very clear what is rendered
by Django and what is rendered by Vue.
Currently the Swiper library is referenced in the base template which
means that its CSS and JS get included and loaded on every page.
However, the Swiper functionality is only used on the landing page. This
leads to redundant requests to load the CSS and JS and may even lead to
hard to debug potential issues with clashing JS or CSS.
This change moves the Swiper JS and CSS to only be included on the
landing page.
Previously some of the Vue code relied on script tags being present in
the host application, to include dependencies such as lodash or marked.
This is not ideal for encapsulation since it means the Vue components
are not self-contained, makes testing harder, etc.
As such, this change replaces the script tag includes with ES6 imports.
Additionally, the lodash dependency (which was used only for debouncing)
is replaced in this change with the vue-debounce library which offers a
debouncing directive. This simplifies the code and avoids potential
gotchas with the this context in the debounced function.
Using a multi-stage build reduces the image size from 1.23GB to 331MB
which means that any node running doccano can now start-up faster.
Additionally, the multi-stage build means that we no longer include
development tools like node or gcc in the production image which reduces
the attack surface of the image.
Hiroki Nakayama
Clemens Wolff
sudodoki
Bramble Xu
root
