With Minio Docker and Windows, the user ID needs
to be set to `0:0` to avoid permission issues.
This change ensures that the Minio container
runs with root privileges on Windows, which
is necessary for proper file access and management.
On Windows systems, Docker volume paths starting
with a single / can be interpreted incorrectly
by the Docker daemon. The double slash (//) helps
Docker on Windows properly interpret the path as
an absolute path within the container, ensuring
that the working directory is correctly set
when running mail-related yarn commands.
We had lot of problems with the previous env.d system.
Users were often confused by the need to change
the env.d files manually, leading to issues
when using the project locally.
This commit introduces a new system that uses
.env.local files, which are automatically created
and can be modified by users without affecting
the original env.d files. This should simplify
the development process and reduce confusion by
removing the need to manually edit env.d files.
In order to speed the rebuild of images, the --no-cache option is
removed by default. If we want to build the images without cache, the
cache paramter must be used.
We want to run the e2e tests using the frontend and y-provider
production images. We created a dedicated compose file adding just
missing services. These services are built in the CI.
We want a serice in compose starting the frontend application in
development mode. We want to take the advantage of the hot reload
module, so the sources are mounted inside the container.
The frontend-dev service is in fact using the production image. We
rename it in frontend accordingly with what it really does. We also have
to change name rules in Makefile to be consistent.
The run command is not starting the frontend application. We change the
run commands. The run command is strating everything. The run-backend
command is starting all services needed to use the backend application.
We need to improve security on the access to The collaboration server
We can use the same pattern as for media files leveraging the nginx
subrequest feature.
We were providing a frontend development container
to the developers, but it was not working properly.
Problem of hot reload was present for Windows and
Linux users.
We stop to provide this development container and
we will provide a container connected to the build
of the frontend.
You can still access the frontend after bootstrap
on the "localhost:3000", but if you want to develop
you will have to install the frontend dependencies
localy and run the frontend in development mode.
This will be more efficient and will avoid the
problem of hot reload, and right on folder access.
Dockerize the frontend development environment
to make it easy to display the frontend
development environment in the browser.
We don't mix it with the command `make run` to
let it kind of optional to run the frontend
in a docker container. We let it optional because
the hot reload doesn't work well in the docker
container. The volume synch make it a bit slower
as well. So, we let the developer decide to run
the frontend in a docker container or not.
We will need object storage to store our document content which comes
as a big json object. Storing it in object storage will offer us
versioning, robustness and scalability.
Add a test to check the pdf export of the
impress app.
It intercept the download of the PDF and
read its content.
We can assert that the template is correctly
rendered, and that the pad text is present as
well.
Create the create_demo command.
It creates a demo template for the backend.
We add it in the makefile bootstrap.
We force the template id, this id is the same as
used in the frontend for the moment.
When the template feature will be created in
the frontend side we will not have to force
it anymore.
This project was copied and hacked to make a POC in a 2-day hackathon.
We need to clean and refactor things in order to get a first version
of the product we want.