La Chariotte

La Chariotte est une application de gestion de commandes groupées.

Elle est publiée sous licence libre Affero GPL, développée et maintenue par Hashbang.

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.

É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 :

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 :

python3 -m venv .venv

Une fois l'environnement virtuel installé, vous pouvez l'activer :

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 pour les installer.

Ensuite, vous pouvez récupérer les dépendances python :

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).

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 :

CREATE ROLE chariotte WITH
	LOGIN
	NOSUPERUSER
	CREATEDB
	NOCREATEROLE
	INHERIT
	NOREPLICATION
	CONNECTION LIMIT -1
	PASSWORD 'xxxxxx';

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.

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 :

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) :

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 :

npm install bulma

Vous aurez aussi besoin de sass :

npm install -g sass

Vérifiez que vous utilisez la bonne version de sass :

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.

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 :

sass --no-source-map ./la_chariotte/static/sass/style.sass:./la_chariotte/static/css/app.css

Lancer les tests

Lancer les tests avec pytest :

pytest

Si il y a des erreurs isort, on peut lancer isort pour trier les fichiers :

isort .

Si il y a des erreurs black, on peut lancer black pour linter le code :

black .

Tests de l'envoi de mails

Pour tester l'apparence des mails, on peut utiliser Sendria :

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 :

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