To be able to test with dummy data, we need to create
our dev users from the demo and to give them access to
the docs.
The sub is the unicity of the user for our oidc provider,
so we need to know the sub to be able to create
correctly the user, it is why we set the sub
as the email of the user in the realm.json file.
Added:
- 🛂(frontend) Manage the document's right (#75)
- ✨(frontend) Update document (#68)
- ✨(frontend) Remove document (#68)
- 🐳(docker) dockerize dev frontend (#63)
- 👔(backend) list users with email filtering (#79)
- ✨(frontend) add user to a document (#52)
- ✨(frontend) invite user to a document (#52)
- 🛂(frontend) manage members (update role / list / remove) (#81)
- ✨(frontend) offline mode (#88)
- 🌐(frontend) translate cgu (#83)
- ✨(service-worker) offline doc management (#94)
- ⚗️(frontend) Add beta tag on logo (#121)
Changed:
- ♻️(frontend) Change site from Impress to Docs (#76)
- ✨(frontend) Generate PDF from a modal (#68)
- 🔧(helm) sticky session by request_uri for signaling server (#78)
- ♻️(frontend) change logo (#84)
- ♻️(frontend) pdf has title doc (#84)
- ⚡️(e2e) unique login between tests (#80)
- ⚡️(CI) improve e2e job (#86)
- ♻️(frontend) improve the error and message info ui (#93)
- ✏️(frontend) change all occurences of pad to doc (#99)
Fixed:
- 🐛(frontend) Fix the break line when generate PDF (#84)
Delete:
- 💚(CI) Remove trigger workflow on push tags on CI (#68)
- 🔥(frontend) Remove coming soon page (#121)
We will need to store more than a file for a document: multiple languages,
images, etc. For this, the document ID should be a folder and the content
a file in this folder.
We override the perform_create method of
the DocumentViewSet to save the document with
the id provided if a id is provided in the request.
We do that because in offline mode we will create
the document locally and we will need to save it
with the id created locally to have our next
requests to the server to be able to find the
document with the id provided.
user field was displaying the userid, but we
need to return the user object on the
DocumentAccessSerializer, so we can show the
user email on the frontend.
We add the user_id field in write_only mode, so
we can keep create and update.
The linter in the CI was checking only the
impress directory. We were passing near some lint
issues. Now the linter checks the whole backend
directory.
We need to search users by their email.
For that we will use the trigram similarity algorithm
provided by PostgreSQL. To use it we have to
activate the pg_trgm extension in postgres db.
To query the email we will use the query param
`q`.
We have another query param `document_id`, it is
necessary to exclude the users that have already
access to the document.
We want to be able to share a document with a person even if this person
does not have an account in impress yet.
This code is ported from https://github.com/numerique-gouv/people.
The default Logout view provided by Mozilla Django OIDC is not suitable
for the Agent Connect Logout flow.
Previously, when a user was logging-out, only its Django session was ended.
However, its session in the OIDC provider was still active.
Agent Connect implements a 'session/end' endpoint, that allows services to
end user session when they logout.
Agent Connect logout triggers cannot work with the default views implemented
by the dependency Mozilla Django OIDC. In their implementation, they decided
to end Django Session before redirecting to the OIDC provider.
The Django session needs to be retained during the logout process.
An OIDC state is saved to the request session, pass to Agent Connect Logout
endpoint, and verified when the backend receives the Logout callback from Agent
Connect. It seems to follow OIDC specifications.
If for any reason, the Logout flow cannot be initiated with Agent Connect,
(missing ID token in cache, unauthenticated user, etc), the user is redirected
to the final URL, without interacting with Agent Connect.
Prepare adding advanced authentication features. Create a dedicated
authentication Python package within the core app.
This code organization will be more extensible.
Versions are retrieved directly from object storage and served on API
endpoints. We make sure a user who is given access to a document will
only see versions that were created after s.he gained access.
The content field is a writable property on the model which is persisted
in object storage. We take advantage of the versioning, robustness and
scalability of S3.
We would like to duplicate a template from the frontend.
For that we need to access the css and code of the template.
So we add the css and code to the template endpoint.
For the demo to be compatible with the new template
editor, we need to add the json file that setup
correctly the editor.
We are able to read and use it, but not edit it,
because the demo is in is_public mode.
We want to be able to update the css and code of
a template from the update endpoint.
This commit adds the css and code fields to the
TemplateSerializer.
partial_update action was missing for the permission.
So when we were patching the template,
it was not working.
This commit adds the partial_update action
to the abilities.
To save the template code editor content,
we need to add a new column on the Template model.
It is a JSONField that will store the code editor content.
We could in the future make an implementation to
save the code editor content in Minio.
We were converting from markdown to html, but the
frontend can provide the body in html format, so
wa can avoid the conversion.
Solution:
Add body type on generate-document endpoint
to allow to choose between markdown and html.
mozilla-django-oidc didn't add the https://
prefix to the redirect_uri.
We set the option SECURE_PROXY_SSL_HEADER to
('HTTP_X_FORWARDED_PROTO', 'https') in the
settings.py file to force the https prefix.
Enabled Dockerflow Django app by activating liveness probes. The previously
unavailable routes such as `__heartbeat__` and `__lbheartbeat__` are now
accessible. New endpoints include:
* GET /__version__
* GET /__heartbeat__
* GET /__lbheartbeat__
In development, sessions are saved in local memory. It's working well,
however it doesn't adapt to a kubernetized setup. Several pods need
to access the current sessions, which need to be stored in a single
source of truth.
With a local memory cache, pods cannot read session saved in other pods.
We end up returning 401 errors, because we cannot authenticate the user.
I preferred setting up a proper cache than storing sessions in database,
because in the long run it would be a performance bottleneck. Cache will
decrease data access latency when reading current sessions.
I added a Redis cache backend to the production settings. Sessions would
be persisted to Redis. In K8s, a Redis operator will make sure the cached
data are not lost.
Two new dependencies were added, redis and django-redis.
I followed the installation guide of django-redis dependency. These
setting were tested deploying the app to a local K8s cluster.
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.
When we converted from markdown to html,
we didn't format the html, so it was displayed
like a string in our pdf.
We now format_html the html before we generate
the pdf.
We want to be able to control who can access a template via roles.
I added this feature on the TeamAccess model assuming that the teams
to which a user belongs can be retrieved via a `get_teams` method on
the user model. The idea is that this method will get the teams either
via a call to an external API or directly from the OIDC token upon
user login. This list of teams will probably have to be cached for
each user.
The local deployment of the Production image through docker-compose was
failing due to issues in the Django configurations, influenced by Joanie.
The bug stemmed from a dependency on a development-specific package
(drf-spectacular-sidecar) while attempting to run the application in
production mode.
Changes Made:
- Introduced new Django settings for local demo environments.
