diff --git a/.readthedocs.yaml b/.readthedocs.yaml new file mode 100644 index 0000000..3a2576b --- /dev/null +++ b/.readthedocs.yaml @@ -0,0 +1,12 @@ +version: 2 +build: + os: ubuntu-22.04 + tools: + python: "3.11" + +mkdocs: + configuration: mkdocs.yml + +python: + install: + - requirements: docs/requirements.txt diff --git a/README.md b/README.md index 5764df4..9a70a1f 100644 --- a/README.md +++ b/README.md @@ -1,308 +1,12 @@ # La Chariotte - + -La Chariotte est une application de gestion de commandes groupées. +La Chariotte is a web application to handle grouped orders. -Elle est publiée sous licence libre Affero GPL, développée et maintenue par [Hashbang](https://hashbang.fr/). +- [Public server](https://chariotte.fr) +- [Online documentation](https://docs.chariotte.fr) -## Contribuer - -Si vous souhaitez contribuer au projet de la Chariotte, merci beaucoup ! - -La permière étape est de cloner le projet et d'obtenir le statut de développeur. Une fois que c'est fait, vous pouvez : - -- choisir une tâche dans le board que vous voulez réaliser, et vous l'assigner - si vous ne savez pas quelle tâche faire, n'hésitez pas à écrire à laetitia@chariotte.fr -- créer une nouvelle branche **à partir de develop** dont le nom dira ce que vous voulez faire -- réaliser la tâche, sans oublier d'écrire et de lancer les tests (voir plus bas) -- créer une Merge Request, contenant le plus de détails possible sur ce que vous avez fait - -Ensuite, un mainteneur de la Chariotte pourra relire votre code et proposer des améliorations/poser des questions si nécessaire. Seuls les mainteneurs peuvent merger dans develop et main. - -Encore merci, et bon code ! - -## Versions - semantic versionning - -Les fonctionnalités développées dans les différentes versions sont listées dans le fichier [CHANGELOG.md](https://gitlab.com/hashbangfr/la_chariotte/-/blob/main/CHANGELOG.md). - -Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter : - -le numéro de version MAJEUR quand il y a des changements non rétrocompatibles, -le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles, -le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles. - -La version est à mettre à jour dans `la_chariotte.__init__.py` lors des releases. - -## Développement - -Cloner le projet : -```bash -git clone git@gitlab.com:hashbangfr/la_chariotte.git -``` - -### Environnement virtuel. - -Pour éviter que les bibliothèques nécessaires au projet ne rentrent en conflit avec celles de votre système, il peut être utile d'installer un environnement virtuel : - -```bash -python3 -m venv .venv -``` - -Une fois l'environnement virtuel installé, vous pouvez l'activer : - -```bash -source .venv/bin/activate -``` - -### Dépendances - -La Chariotte utilise Weasyprint pour la génération de PDFs, qui nécessite certains paquets sur votre machine. Vous pouvez suivre [les instructions de cette page](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) pour les installer. - -Ensuite, vous pouvez récupérer les dépendances python : -```bash -pip install -r requirements-dev.txt -``` - -### Base de données - -La Chariotte nécessite une base de données, et est actuellement compatible avec PostgreSQL ([instructions d'installation ici](https://www.digitalocean.com/community/tutorials/how-to-install-postgresql-on-ubuntu-20-04-quickstart)). - -Pour le développement, nous vous conseillons de créer une base de données nommée ```chariotte``` accessible par l'utilisateur et le mot de passe du même nom. - -Dans une invite postgresql, entrez ceci : - -```SQL -CREATE ROLE chariotte WITH - LOGIN - NOSUPERUSER - CREATEDB - NOCREATEROLE - INHERIT - NOREPLICATION - CONNECTION LIMIT -1 - PASSWORD 'xxxxxx'; -``` -```SQL -CREATE DATABASE chariotte - WITH - OWNER = chariotte - ENCODING = 'UTF8' - CONNECTION LIMIT = -1 - IS_TEMPLATE = False; -``` - -### Fichier de configuration - -Créez un fichier de configuration dans lequel vous pourrez spécifier la configuration qui est utile pour vous. Nous allons le nommer ici ```local_settings.py```. - -```python -from la_chariotte.settings import * - -DATABASES = { - "default": { - "ENGINE": "django.db.backends.postgresql", - "NAME": "chariotte", - "USER": "chariotte", - "PASSWORD": "chariotte", - "HOST": "localhost", - } -} -``` - -### Lancement du serveur - -Tout devrait être maintenant prêt pour pouvoir lancer le serveur : - -```shell -python manage.py migrate --settings=local_settings -python manage.py runserver --settings=local_settings -``` - -Pour créer un superutilisateur, qui aura accès à l'interface admin (/admin) : -```shell -python manage.py createsuperuser --settings=local_settings -``` - -### Travailler sur le frontend - -Nous utilisons bulma comme framework CSS. Vous pouvez l'installer en utilisant la commande suivante : - -```bash -npm install bulma -``` - -Vous aurez aussi besoin de sass : -```bash -npm install -g sass -``` - -Vérifiez que vous utilisez la bonne version de sass : - -```bash -sass --version -# used for developement: 1.59.3 compiled with dart2js 2.19.4 -``` - -Recompiler dès que des changements sont detectés dans les fichiers scss. - -```bash -sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css -``` - -Ou bien préférez compiler vers CSS au coup à coup : -```bash -sass --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css -``` - -### Lancer les tests - -Lancer les tests avec pytest : -```bash -pytest -``` - -Si il y a des erreurs [isort](https://pycqa.github.io/isort/), on peut lancer isort pour trier les fichiers : - -```bash -isort . -``` - -Si il y a des erreurs [black](https://black.readthedocs.io/en/stable/), on peut lancer black pour linter le code : - -```bash -black . -``` - -### Tests de l'envoi de mails - -Pour tester l'apparence des mails, on peut utiliser [Sendria](https://github.com/msztolcman/sendria) : -```bash -pip install sendria -sendria --db mails.sqlite -$NAVIGATOR http://127.0.0.1:1080 -``` - -Attention : si vous n'activez pas `sendria --db mails.sqlite` quand vous travaillez en local, vous aurez une erreur en commandant : `[Errno 111] Connection refused`. - -## Architecture de l'application - -Les différentes applications Django créées sont : - -- ``order``, pour gérer tout ce qui tourne autour des commandes -- ``accounts``, pour gérer la création de comptes. Pour la connexion, la déconnexion et le changement de mot de passe, on utilise l'application auth intégrée à Django. -- ``mail``, pour l'envoi des mails. - -A l'état actuel, le diagramme de classes est le suivant : - -```mermaid -classDiagram - GroupedOrder "item_set" <-- Item - GroupedOrder "order_set" <-- Order - Order "ordered_items" <-- OrderedItem - Item "orders" <-- OrderedItem - OrderAuthor "author" <-- Order - CustomUser "grouped_orders" <-- GroupedOrder - - class GroupedOrder{ - name - deadline : DateTime - delivery_date : Date - place - description - orga : CustomUser - total_price - } - class Item{ - name - grouped_order : GroupedOrder - ordered_nb - total_price - max_limit - } - class Order{ - grouped_order : GroupedOrder - author : OrderAuthor - price - created_date - note - } - class OrderedItem{ - order : Order - nb - item : Item - } - class OrderAuthor { - first_name - last_name - phone - email - } - class CustomUser{ - first_name - last_name - email - } -``` - -## Conventions de nommage - -### Nommage des branches - -Chaque branche doit être nommée sous la forme `category[/ticket-ref]/description`. -*category* détermine le type de modification que vous comptez effectuer au sein de la branche : - - - `feature` pour ajouter une fonctionnalité au projet - - `fix` pour corriger un bug - - `test` pour effectuer des changements n'étant associé à aucun besoin déjà spécifié - - `doc` pour effectuer des changements relatifs à la documentation (readme notamment) - - `refactor` pour effectuer un changement au sein du code sans conséquence sur l'application - -Vous pouvez ajouter une catégorie si le besoin s'en fait sentir, tout en s'assurant que le sens soit bien compréhensible de l'extérieur. - -Entre la catégorie et la description peut s'insérer la référence du ticket Gitlab relatif à la branche. - -La description de la branche, en anglais et en kebab-case, doit décrire de manière très succinte l'objectif de la branche : dans quel but elle a été créée sans entrer dans le détail. - - Bons exemples : - - - `feature/72/improve-pdf-generation` - - `fix/117/deadline-increments-on-duplicated-commands` - - `doc/explain-conventions` - - `refactor/99/is_ongoing-to-is_open` - - Mauvais exemples : - - - `fix-some-stuff` - - `readme` - - `feature/add-a-cool-ui-element-when-the-cursor-passes-over-the-calendar-where-the-user-can-also-choose-the-associated-hour` - - `fix/edit-order/views/order.py-to-replace-is_ongoing-by-is_open` - -### Noms des commits - -Les noms de commits doivent être constitués de deux parties : un sujet et un corps (optionnel). -Le sujet fait office de titre du commit ; il se suffit souvent à lui-même et doit expliquer brièvement le but du commit. -Si besoin, le message de commit peut être enrichi d'un corps qui permet de détailler plus en détails ce qui a été modifié et pourquoi (mais pas comment !). - -Les noms des commits doivent respecter ces 7 règles d'or pour garantir une homogénéité dans le projet: - -- Sépare le sujet du corps avec une ligne vide -- Limite la ligne de sujet à 50 caractères -- Met une majuscule à la ligne de de sujet -- Ne finis pas la ligne de sujet avec un point -- Utilise le mode impératif dans la ligne de sujet (IMPORTANT) -- Limite la taille de ligne (*wrap*) du corps à 72 caractères -- Utilise le corps pour expliquer le quoi et le pourquoi (et pas le comment) - -Les détails de cette méthode sont détaillés dans ce tuto : https://cbea.ms/git-commit/ - -Bons exemples : - -- `Refactor system X for readability` -- `Remove deprecated method` -- `Release version 1.4.2` - - Mauvais exemples : - -- `Changing behaviour of X` -- `add submit button.` -- `Edit order.py line 72 to improve efficiency by adding recursive algorithm` +This project has been initially developped and published by [Hashbang](https:// +hashbang.fr/) under an [Affero GPLv3](LICENSE) license, and is now maintained +and developed by a team of volunteers. diff --git a/docs/assets/logo.png b/docs/assets/logo.png new file mode 100644 index 0000000..ab6ce16 Binary files /dev/null and b/docs/assets/logo.png differ diff --git a/docs/changelog.md b/docs/changelog.md new file mode 100644 index 0000000..42333f1 --- /dev/null +++ b/docs/changelog.md @@ -0,0 +1,11 @@ +# Changelog + +Given a version number `MAJOR`.`MINOR`.`PATCH`: + +- `MAJOR` is updated when there are **incompatible changes**, +- `MINOR` is updated when there are **backwards-compatible feature additions**, +- `PATCH` is updated when there are **backwards-compatible bug fixes**. + +### 1.0.0 (date) + +- Basic features. diff --git a/docs/contributing/contributing.md b/docs/contributing/contributing.md new file mode 100644 index 0000000..6454e09 --- /dev/null +++ b/docs/contributing/contributing.md @@ -0,0 +1,62 @@ +# Contributing + +You want to contribute to the project ? First, thank you very much! We'll try to do our best to help you getting started. + +The first step is to clone the project, you can find more information about that in the [getting started guide](../install.md). Once that's done, you can: + +- choose a task [on the board]() and assign it to yourself - if you don't know which task to do, feel free to reach to us. +- create a new branch **from develop** naming it to reflect what you want to do +- complete the task, without forgetting to write and run tests (see below) +- create a Merge Request, containing as many details as possible about what you have done + +Then, a maintainer will be able to review your code and suggest improvements/ask questions if necessary. Only maintainers can merge into develop and main. + +Thanks again, and happy coding! + +## Working on the frontend + +To recompile the files as soon as changes are detected in the scss files. + +```bash +sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css +``` + +## Running tests + +Run tests with `pytest`: + +```bash +pytest +``` + +## Formatting your code + +Once you're ready, you'll need to ensure your code is formatted the right way. +We're using [isort](https://pycqa.github.io/isort/) to fix the import order, +and [black](https://black.readthedocs.io/en/stable/) for general linting. + +You can run them with: + +```bash +isort . +black . +``` + +## Working with emails + +To test the appearance of emails, you can use [Sendria](https://github.com/msztolcman/sendria): + +```bash +pip install sendria +sendria --db mails.sqlite +$NAVIGATOR http://127.0.0.1:1080 +``` + +## Docs + +We're using [MkDocs](https://www.mkdocs.org/) for this documentation. If you want to +build it locally, just run: + +```bash +mkdocs serve +``` diff --git a/docs/contributing/naming.md b/docs/contributing/naming.md new file mode 100644 index 0000000..c5f8780 --- /dev/null +++ b/docs/contributing/naming.md @@ -0,0 +1,66 @@ +# Naming Conventions + +We're trying to enforce some naming rules for our work. The goal is to be consistent. + +## Git branches + +Each git branch should be named in the form `category[/ticket-ref]/description`. + +`category` determines the type of change you intend to make within the branch: + +- `feature` to add a feature to the project +- `fix` to correct a bug +- `test` for making changes that are not associated with any specified need +- `doc` for making changes related to documentation (readme in particular) +- `refactor` for making a change within the code without consequence on the application + +You can add a category if needed, making sure the meaning is easily understandable from the outside. + +Between the category and description, the Gitlab ticket reference related to the branch may be inserted. + +The branch description, in English and in kebab-case, must briefly describe the purpose of the branch: the purpose for which it was created without going into detail. + +Good examples: + +- `feature/72/improve-pdf-generation` +- `fix/117/deadline-increments-on-duplicated-commands` +- `doc/explain-conventions` +- `refactor/99/is_ongoing-to-is_open` + +Bad examples: + +- `fix-some-stuff` +- `readme` +- `feature/add-a-cool-ui-element-when-the-cursor-passes-over-the-calendar-where-the-user-can-also-choose-the-associated-hour` +- `fix/edit-order/views/order.py-to-replace-is_ongoing-by-is_open` + +## Git commits + +Commit names should consist of two parts: a subject and a body (optional). + +The subject acts as the title of the commit; it often suffices by itself and should briefly explain the purpose of the commit. +If needed, the commit message can be enriched with a body that allows for more detailed explanations of what was modified and why (but not how!). + +Commit names must follow these 7 golden rules to ensure uniformity in the project: + +- Separate the subject from the body with a blank line +- Limit the subject line to 50 characters +- Capitalize the subject line +- Do not end the subject line with a period +- Use imperative mood in the subject line (IMPORTANT) +- Limit the line size (*wrap*) of the body to 72 characters +- Use the body to explain the what and the why (and not the how) + +Details of this method can be found in this tutorial: https://cbea.ms/git-commit/ + +Good examples: + +- `Refactor system X for readability` +- `Remove deprecated method` +- `Release version 1.4.2` + +Bad examples: + +- `Changing behaviour of X` +- `add submit button.` +- `Edit order.py line 72 to improve efficiency by adding recursive algorithm` diff --git a/docs/contributing/releasing.md b/docs/contributing/releasing.md new file mode 100644 index 0000000..ffa1fd4 --- /dev/null +++ b/docs/contributing/releasing.md @@ -0,0 +1,13 @@ +# Releasing a new version + +## Semantic versioning + +The features developed in the various versions are listed in the [changelog](../changelog.md) file. + +Given a version number MAJOR.MINOR.PATCH, increment: + +- the MAJOR version when there are incompatible changes, +- the MINOR version when there are backwards-compatible feature additions, +- the PATCH version when there are backwards-compatible bug fixes. + +The version should be updated in `la_chariotte.__init__.py` during releases. diff --git a/docs/deploy.md b/docs/deploy.md new file mode 100644 index 0000000..7f1723a --- /dev/null +++ b/docs/deploy.md @@ -0,0 +1,107 @@ +# How to deploy + +!!! info "This is how **we** deploy" + + This page describes how the main instance is deployed, and is mainly meant as a + way to share the knowledge. You can obviously do things differently. + +## Services + +"La chariotte" uses different domains: + +- **docs.chariotte.fr**, the docs you are reading now. It's handled by [readthedocs.org](https://readthedocs.org). +- **chariotte.fr**, the main instance. It's deployed on Alwaysdata +- **blog.chariotte.fr**, our blog. It's [a static website](https://gitlab.com/la-chariotte/la-chariotte.gitlab.io) deployed on Gitlab pages. + +## The main instance + +### Alwaysdata, our hosting provider + +[Alwaysdata](https://www.alwaysdata.com) offers [a free plan for open source +projects](https://www.alwaysdata.com/en/open-source/), which we are using for +the main instance of la chariotte. + +Thanks to them for supporting open source! + +### Getting access + +To get access, you'll need to generate an ssh keypair, and give your public key to a known admin. + +```bash +ssh-keygen +``` + +This will generate a private a public key. You need to share the **public** key. +On unix systems, it's stored under `~/.ssh/id_rsa.pub` by default. + +### Connecting to ssh + +Once your key is generated and you're known to the server, you can connect there. + +```bash +ssh chariotte@ssh-chariotte.alwaysdata.net +``` + +### Configuration file + +The chariotte application is run by [uwsgi](https://uwsgi-docs.readthedocs.io/ +en/latest/), managed by AlwaysData. + +The production settings are stored in `~/ la_chariotte/prod_settings.py`, and +the secrets are defined in the admin console. + +### The different sites + +In the AD console, here are the defined sites: + +- `app.chariotte.fr`, redirecting to `chariotte.fr` +- `chariotte.fr/static`, hosting the static files, it just serves the collected static files stored in `/static/` +- `chariotte.fr`, the main website, defined in the next section + +`chariotte.fr` is configured as a Python WSGI app: + +- application path: `/la_chariotte/la_chariotte/wsgi.py` +- working directory: `/la_chariotte` +- venv location: `/venv` + +Environment variables: + +``` +DJANGO_SETTINGS_MODULE=prod_settings +``` + +### How to deploy + +To deploy a new version, we'll need to: + +- get the new code +- update the database +- collect the static files +- restart the daemon + +Here's how: + +```bash +# Activate the venv +source venv/bin/activate +cd la_chariotte + +# Get the code +git fetch +git checkout tag # if we're using a tag, otherwise, just checkout the main branch + +python manage.py updatedb +python manage.py collectstatic +``` + +Then you'll need to restart the server from AD's interface. + +### What about SSL certificates? + +The SSL certificates are issued directly by AlwaysData (they use [Let's Encrypt] +(https://letsencrypt.org/) behind the scenes) + +## Mails + +Mails are hosted by alwaysdata, as part of their opensource plan. + diff --git a/docs/development/architecture.md b/docs/development/architecture.md new file mode 100644 index 0000000..9268e47 --- /dev/null +++ b/docs/development/architecture.md @@ -0,0 +1,59 @@ +# Application Architecture + +The various Django apps created are: + +- ``order``, to manage everything around the orders +- ``accounts``, to manage account creation. For logging in, logging out, and changing passwords, we use Django’s built-in auth application. +- ``mail``, for sending emails. + +At the moment, the class diagram is as follows: + +```mermaid +classDiagram + GroupedOrder "item_set" <-- Item + GroupedOrder "order_set" <-- Order + Order "ordered_items" <-- OrderedItem + Item "orders" <-- OrderedItem + OrderAuthor "author" <-- Order + CustomUser "grouped_orders" <-- GroupedOrder + + class GroupedOrder{ + name + deadline : DateTime + delivery_date : Date + place + description + orga : CustomUser + total_price + } + class Item{ + name + grouped_order : GroupedOrder + ordered_nb + total_price + max_limit + } + class Order{ + grouped_order : GroupedOrder + author : OrderAuthor + price + created_date + note + } + class OrderedItem{ + order : Order + nb + item : Item + } + class OrderAuthor { + first_name + last_name + phone + email + } + class CustomUser{ + first_name + last_name + email + } +``` diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..38eb6b4 --- /dev/null +++ b/docs/index.md @@ -0,0 +1,3 @@ +# La chariotte - Documentation + +![Logo](assets/logo.png) diff --git a/docs/install.md b/docs/install.md new file mode 100644 index 0000000..0664733 --- /dev/null +++ b/docs/install.md @@ -0,0 +1,126 @@ +First, clone the project + +```bash +git clone git@gitlab.com:la-chariotte/la_chariotte.git +``` + +## Virtual environment + +To prevent the project's necessary libraries from conflicting with those on your system, it may be beneficial to install a virtual environment: + +```bash +python3 -m venv .venv +``` + +Once the virtual environment is installed, you can activate it: + +```bash +source .venv/bin/activate +``` + +## Installing the dependencies + +!!! info "Weasyprint" + + We are using [Weasyprint](https://weasyprint.readthedocs.io/) for `.pdf` generation, which requires certain packages on your machine. You can follow [the instructions on this page](https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#installation) to install them. + +Then, you can retrieve the Python dependencies: + +```bash +pip install -e ".[dev]" +``` + +And the frontend dependencies: + +=== "Yarn" + + ```bash + npm install + ``` + +=== "npm" + ```bash + yarn install + ``` + +## Setting up the database + +We recommend using PostgreSQL for now ([installation instructions here](https://www.digitalocean.com/community/tutorials/how-to-install-postgresql-on-ubuntu-20-04-quickstart)). + +For development, we recommend creating a database named ```chariotte``` accessible by the user and password of the same name. + +In a PostgreSQL prompt, enter this: + +```sql +CREATE ROLE chariotte WITH + LOGIN + NOSUPERUSER + CREATEDB + NOCREATEROLE + INHERIT + NOREPLICATION + CONNECTION LIMIT -1 + PASSWORD 'xxxxxx'; +``` +```sql +CREATE DATABASE chariotte + WITH + OWNER = chariotte + ENCODING = 'UTF8' + CONNECTION LIMIT = -1 + IS_TEMPLATE = False; +``` + +## Create a configuration file + +Create a local configuration file: + +```python title="local_settings.py" +from la_chariotte.settings import * + +DATABASES = { + "default": { + "ENGINE": "django.db.backends.postgresql", + "NAME": "chariotte", + "USER": "chariotte", + "PASSWORD": "chariotte", + "HOST": "localhost", + } +} +``` + +## Compile the CSS files + +We use bulma as a CSS framework. + +Make sure you are using the correct version of sass: + +```bash +sass --version +# used for development: 1.59.3 compiled with dart2js 2.19.4 +``` + +Recompile as soon as changes are detected in scss files. + +```bash +sass --watch --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css +``` + +Or prefer to compile to CSS on a per-occurrence basis: +```bash +sass --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css +``` + +## Start the server + +Everything should now be ready to start the server: + +```shell +python manage.py migrate --settings=local_settings +python manage.py runserver --settings=local_settings +``` + +To create a superuser, who will have access to the admin interface (/admin): +```shell +python manage.py createsuperuser +``` diff --git a/docs/requirements.txt b/docs/requirements.txt new file mode 100644 index 0000000..12275a7 --- /dev/null +++ b/docs/requirements.txt @@ -0,0 +1,3 @@ +mkdocs==1.5.3 +pymdown-extensions==10.4 +mkdocs-material==9.4.14 diff --git a/docs/settings.md b/docs/settings.md new file mode 100644 index 0000000..4580658 --- /dev/null +++ b/docs/settings.md @@ -0,0 +1,29 @@ +# Settings + +Here are the useful settings you can define. We're generally extending [Django settings](https://docs.djangoproject.com/en/4.2/ref/settings/), so any setting there could be used here. + +This page documents the additional setting. + +## CONTACT_MAIL + +The contact mail that will be displayed at the bottom of the page. + +```python title="chariotte_settings.py" +CONTACT_MAIL = "name@example.org" +``` + +## GITLAB_LINK + +The URL to the git repository. + +```python title="chariotte_settings.py" +GITLAB_LINK = "https://gitlab.com/your-repository" +``` + +## PROJECT_NAME + +This is the main name of the project. By default it's set to `"La Chariotte"` + +```python title="chariotte_settings.py" +PROJECT_NAME = "Groupement d'achat du CRAC" +``` diff --git a/la_chariotte/settings.py b/la_chariotte/settings.py index 7c85c4d..284f5b9 100644 --- a/la_chariotte/settings.py +++ b/la_chariotte/settings.py @@ -7,7 +7,7 @@ from sentry_sdk.integrations.django import DjangoIntegration BASE_DIR = Path(__file__).resolve().parent.parent BASE_URL = os.getenv("BASE_URL", "http://127.0.0.1:8000") PROJECT_NAME = os.getenv("PROJECT_NAME", "La Chariotte") -GITLAB_LINK = "https://gitlab.com/hashbangfr/la_chariotte" +GITLAB_LINK = "https://gitlab.com/la-chariotte/la_chariotte" CONTACT_MAIL = "laetitia@chariotte.fr" # SECURITY WARNING: keep the secret key used in production secret! diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..2d6ca01 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,47 @@ +site_name: La chariotte +site_description: An application for grouped-orders +repo_name: la-chariotte/la_chariotte +repo_url: https://gitlab.com/la-chariotte/la_chariotte +nav: + - How-tos: + - Getting started: install.md + - Contributing: + - How to: contributing/contributing.md + - Naming conventions: contributing/naming.md + - Releasing: contributing/releasing.md + - Developer: + - Architecture: development/architecture.md + - Configuration: + - Settings: settings.md + - Deployment: deploy.md + - Changelog: changelog.md +theme: + name: material + homepage: https://chariotte.fr + palette: + - scheme: 'default' + media: '(prefers-color-scheme: light)' + primary: 'custom' + toggle: + icon: 'material/lightbulb' + name: 'Switch to dark mode' + - scheme: 'slate' + media: '(prefers-color-scheme: dark)' + primary: 'custom' + toggle: + icon: 'material/lightbulb-outline' + name: 'Switch to light mode' + features: + - navigation.sections + - navigation.footer +markdown_extensions: + - pymdownx.magiclink + - admonition + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format + - pymdownx.tabbed: + alternate_style: true + combine_header_slug: true diff --git a/pyproject.toml b/pyproject.toml index e3efe3f..577cfad 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -11,11 +11,12 @@ dependencies = [ "django>=4,<5", "psycopg2-binary>=2,<3", "sentry-sdk<1", - "xhtml2pdf", - "icalendar", - "base36", - "django-weasyprint", - "html2text", + "xhtml2pdf>=0.2.11,<1", + "icalendar>=5.0.7,<6", + "base36>=0.1.1,<1", + "django-weasyprint==1.1.0.post1", # see below + "weasyprint==52.5", # pin weasyprint to not depend on latest libpango + "html2text>=2020.1.16", ] [tool.setuptools] @@ -39,6 +40,7 @@ dev = [ "pytest-django>=4,<5", "pytest-cov>=4,<5", "diff-cover>=4,<5", + "pymdown-extensions==10.4", "pytest-black<1", ]