fairnesscoop/permacoop

Open source and eco-designed ERP solution for worker-owned businesses.

permacoop's Issues

[EPIC] ETQ salariés je peux modérer les congés des autres salariés

Contexte*

Un salarié peut prendre des congés mais ceux-ci doivent être accepté par un autre salarié.

User stories

1. ETQ salarié je peux accepter un congé
2. ETQ salarié je peux refuser un congé
3. ETQ que salarié je ne peux ni refuser/ni accepter mes propres demande de congés
4. ETQ que salarié je peux voir un aperçu des demandes de MES demandes de congé ainsi que de leur statut (en cours d'acceptation/ validée / refuser)
5. ETQ que salarié je peux voir un aperçu des demandes des demandes de congé des AUTRES salariés.
6. ETQ que salarié je peux expliquer via un commentaire la raison du refus et de l'acceptation
7. ETQ que salarié je peux voir le détail de ma demande de congé.
8. ETQ que salarié je peux voir le détail des demande de congé des autres salarié.

Dev local : Erreurs 404 lors des appels API

Comportement attendu

Quand je lance make start, je peux me connecter avec le compte [email protected]

Comportement réel

Une erreur 404 apparaît dans la console web

Pour reproduire

• git checkout master
• make start
• Ouvrir http://localhost:3001
• Se connecter avec [email protected] / john
• Constater "Error: undefined" et une erreur 404 http://localhost:3001/api/login dans la console web

Idées de résolution

Visiblement le front se parle à lui-même et pas à l'API

Le pb est probablement dans client/config.js

ETQ Salarié j'ai un onglet TR qui m'indique le nombre de TR qui me seront donnés pour le mois en cours

dans cet onglet le salarié doit voir:
Le nombre de jours ouvrés dans le mois = nombre de tickets restos max du mois
et Soustraits:

• Le nombre de jours de congés
• Le nombre le nombre de jours à temps partiel
• Le nombre de jours (Confs/invitation client) sans TR
• Le nombre de "congés illimités"

Et donc finalement le nombre de tickets resto qui lui seront donnés à la fin du mois et leur valeur.

[tech] Migration Sapper -> SvelteKit

• Refs #271

Prérequis

• #272 (sans tests E2E, aucune façon de garantir l'absence de régression, et on fera la migration dans la peur)
• Rendre le déploiement déclaratif (ex : Ansible) pour faciliter la reconfiguration de Nginx ?

Contraintes

• Pendant le développement, la migration est sans impact pour les personnes utilisatrices de Permacoop, qui en dépendent pour leur activité quotidienne

Critères d'acceptation

• La nouvelle codebase utilise SvelteKit. #277
• La nouvelle codebase utilise la version de SvelteKit la plus à jour au moment de considérer de fermer cette epic.
• La nouvelle implémentation est en production.
• Le tooling (makefile, package.json, etc) a été mis à jour.
• Toutes les fonctionnalités ont été migrées vers client/kit, sans régression à signaler.
• Toute référence à Sapper a disparu.

Implémentation

Solution proposée

Option 3 : migration incrémentale selon le Strangler Fig Pattern. Un dossier client/kit où on migrera petit à petit le client Sapper jusqu'à remplacer totalement ce dernier. Les deux seront déployés en cohabitation pour éviter toute migration brutale (tout code ajouté à client/kit sera immédiatement utilisé en production).

Conséquences

• Le setup local et le déploiement seront mis à jour pour que client/kit et client/legacy soient utilisés en cohabitation.
• Toute nouvelle fonctionnalité devra être implémentée dans client/kit.
• (Idéalement) Toute modification d'une fonctionnalité existante passera en premier lieu par le portage de cette fonctionnalité dans client/kit. Autrement dit, client/legacy est "gelé".

Options envisageables

Dans le respect des contraintes mentionnées plus haut

Option 1
Résumé	Recoder toute l'app en un coup dans une unique PR
Avantages
Risques	Revue de code très difficile voire impossible => risque de régression important. Risque d'abandon par la ou les personnes qui prendront en charge cette masse de travail Parallélisation ou relai du travail entre différentes personnes difficile

Option 2
Résumé	Recoder l'app petit à petit dans un nouveau dossier \client_kit`, puis faire le switch une fois la nouvelle implémentation totalement prête
Avantages
Risques	Risque de régression lors du "switch" final : il faudra quand même une "recette fonctinnelle"

Option 3
Résumé	Recoder l'app petit à petit dans un dossier client_kit, et déployer les deux serveurs (ancien et nouveau) en coexistance. Router les requêtes vers la nouvelle version dès que les pages le permettent, jusqu'à ce que la version SvelteKit couvre toute l'app anciennement codée avec Sapper. C'est le Strangler Fig Pattern
Avantages	Faible risque de régression grâce à la validation in situ des PRs au fur et à mesure de leur déploiement et utilisation par les salarié-es Possibilité d'avancer la migration morceau par morceau, compatible avec du temps mobilisé le vendredi ou en inter-mission
Risques	La migration ne prend pas moins de temps pour autant

Option 4
Résumé	Recréer un frontend non-SvelteKit, par exemple avec une approche hypermedia (Turbo, htmx, templates handlebars ou autre dans le Nest.js)
Avantages	Faible risque de régression grâce à la validation in situ des PRs au fur et à mesure de leur déploiement et utilisation par les salarié-es Possibilité d'avancer la migration morceau par morceau, compatible avec du temps mobilisé le vendredi ou en inter-mission
Risques	La migration nécessite de reconcevoir Permacoop. On ne peut plus "copier-coller du Svelte".</li Nécessiterait de remplacer l'API JSON par une API HTML (autrement dit, des routes "classiques" qui renvoient des templates). C'est donc aussi une reconception du backend, or celui-ci est très bien comme il est.

Implémentation

• #277
• #308
• ...

Contexte supplémentaire

Actuellement, le front-end de permacoop est construit avec les technologies suivantes :

• Svelte
• Le framework Sapper
• Tailwind pour la gestion du CSS

Le développement de Sapper a été arreté en faveur d'un "nouveau" framework nommé Sveltekit

Comme l'indique la documentation Sapper :

Sapper's succesor, is currently available for use. All development efforts moving forward will be focused on SvelteKit.

Sapper est en "maintenance" mais plus aucune fonctionalité sera rajoutée. De ce fait, il est certainement temps de migrer vers SvelteKit

Précédents

• #209

[Bug] Lorsque je crée un congés d'une demi journée, je me retrouve avec 0 ou -0.5

Lorsque je crée un congés sur une journée et que je remplie "toute la journée" à "non" :

J'obtiens le résultat suivant :

Au lieu de la mention "0.5 jour", j'ai "-0.5 jour"

Registre du personnel

TODO: reformuler sous la forme "ETQ"

Problème

La tenue d'un registre du personnel est une obligation légale.

Le nôtre est actuellement un fichier Excel détaché de Permacoop, ce qui rend sa mise à jour difficile.

Solution envisagée

Intégrer une fonction registre du personnel à Permacoop, sous la section "FairRH > Coopérateurs - Salariés".

Idéalement, il faut :

• Une vue tableau intégrée à l'UI, pour visualisation simple
• Un bouton pour exporter au format Excel afin de partager le registre à qui de droit.

Pour cela, plusieurs options :

• Transformer la liste "Coopérateurs - Salariés" existantes pour qu'elle devienne un véritable registre du personnel.
  • Inconvénient : on n'a pas forcément besoin de voir toutes les informations du registre.
• Créer deux onglets "Vue simplifiée" / "Vue registre du personnel" où la seconde affiche les informations attendues dans un registre et déclenche l'apparition d'un bouton "Exporter"

Données

Les champs du registre sont actuellement :

• Matricule
• Nom
• Prénom
• Sexe
• Nationalité
• Emploi occupé
• Date d'entrée
• Date de sortie
• Type de contrat
• Temps partiel/complet (Nb d'heures, 4/5e, etc)
• Statut (Cadre / ETAM / N/C)
• Coeff (??)
• Position (??)
• Autres informations

Toute personne ayant travaillé chez Fairness doit y figurer, même si elle en est partie (auquel cas la "Date de sortie" sera définie).

Permacoop permet déjà de définir une date de sortie. Il faut donc s'assurer que tous les salariés précédents sont bien présents.

A-t-on les données suivantes dans Permacoop ?

• Matricule
• Nationalité
• Sexe
• Coeff
• Position

On pourrait les définir dans une section "Informations complémentaires pour le registre du personnel".

[EPIC] ETQ salarié je souhaite pouvoir saisir mon compte rendu d'activité (CRA)

Contexte :

En tant que salarié, j'ai besoin de pouvoir enregistrer ce que j'ai fait dans ma journée.

User stories :

1. ETQ salarié je peux définir la durée par défaut d'une journée de travail pour mon entreprise.
2. .ETQ salarié je peux configurer la durée d'une journée de travail du projet sur lequel je travaille
3. ETQ salarié je peux choisir de ne pas comptabiliser un jour.
   Un jour non comptabilisé est un jour "offert" au client.

Note :

Une entreprise possède plusieurs projets. Chaque projet peut avoir une durée de journée de travail différente.

Solution du problème de call API SSR/mode client => nginx

Conf nginx :

upstream client {
    server client:3000;
}

upstream www {
	server www:8080;
}

server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://client;
    }

    location /api {
        proxy_pass http://www;
    }
}

Docker compose :

nginx:
    image: nginx:latest
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
    ports:
      - 80:80
    volumes:
      - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf:ro

ETQ que Salarié je veux pouvoir indiqué que je ne souhaite pas recevoir de ticket restaurant pour un jour donné

Un.e salariéé à droit à 1 ticket restaurant pour chaque jour ouvré. Parfois, il arrive qu'il/elle ne souhaite pas en recevoir.
Pour ce faire cet employé.e peut indiquer le jour où il/elle ne souhaite pas le recevoir.

Ne garder le Docker Compose local que pour la base de données

Thoughts?

Plus sérieusement, voici mon raisonnement...

Analyse

Actuellement on utilise un Docker Compose uniquement pour le développement local.

Notre expérience sur Catalogage a montré que, pour des utilisateurs techniques capables d'installer des prérequis (Node, en gros), ça n'est pas nécessaire.

Ça induit peut-être plus de problèmes que ça n'en résout, par exemple les problèmes de permissions, le mapping de volumes pour faire fonctionner le hot reload, voire désormais l'installation de Docker lui-même (Docker Desktop sur Linux ?).

De plus, ça ajoute de la configuration qui n'est pas non plus utilisée pour la prod, donc pas d'avantage de ce côté-là par rapport à un setup "sur l'hôte" classique.

@mmarchois a mentionné avoir retiré Docker pour le dev chez RF. J'aimerais entendre son avis sur l'idée de le retirer de Permacoop aussi.

Proposition

• Retirer de docker-compose.yml les services suivants :

  • api
  • client
  • nginx

• Garder database car l'installation de PostgreSQL est plus fastidieuse que lancer un npm ci pour le client et l'API.

• Réorganiser le Makefile pour que le install, build, start, test, etc se fassent en communiquant avec le client ou l'API via le dossier local.

Par exemple, pour start :

prefix = ./tools/colorize_prefix.sh

start: ## Serve API, client, Tailwind and DB in parallel
	make -j 4 start-api start-client start-tailwind start-db

start-api: ## Run API
	${prefix} [api] 30 "cd server && npm run start:dev"

start-client: ## Run client
	PORT=3001 ${prefix} [client] 31 "cd client && npm run dev"

start-tailwind:
	${prefix} [tailwind] 36 "cd client && npm run watch:tailwind"

start-db:
	${prefix} [db] 34 "${compose} up -d -- database"

make -j est ici utilisé comme un job launcher léger pour lancer tous les serveurs en parallèle.

colorize_prefix.sh est un script à placer dans le repo pour ajouter par exemple ici un [client] colorisé en rouge, permettant de distinguer les logs des divers jobs lancés par make -j.

ETQ utilisateur je peux replier les sections de menus

Description du problème

Actuellement les menus déroulants de Permacoop ne sont pas collapsable : cliquer sur les différentes sections n'a aucun effet. Tous les menus sont donc déroulés.

(Ça résoudrait indirectement un autre problème : le bas du menu n'est pas forcément accessible sur mobile. Mais il faudrait plutôt s'assurer qu'il soit correctement scrollable sur mobile.)

Solution envisagée

• En cliquant une section de menu, faire que celui-ci se replie
• Les menus doivent rester déroulés par défaut (à l'ouverture de la page)

What do you mean by reserved for worker-owned business?

Hi, can anyone use this project? What do you mean by reserved for worker-owned business?

[tech] Update fullcalendar

Passer sur la nouvelle version de fullcalendar + appels api géré par le plugin.

As a developper I would like to use eslint instead of tslint since it has been deprecated

For reference this is the offical eslint configuration for nest

https://github.com/nestjs/nest/blob/master/.eslintrc.js

As a Developer I'd like to lint and prettify my code

Using eslint and prettier to lint and prettify the front-end code base could save a lot of time and avoid many headaches.

Svelte has a eslint configuration available https://github.com/sveltejs/eslint-plugin-svelte3. This configuration in combinaison with eslint recommended and airbnb base ( the full airbnb eslint conf embed rules for react) could be a perfect match.

Here is a configuration example : https://github.com/babichjacob/sapper-typescript-graphql-template/blob/main/.eslintrc.json

ETQ Salarié Je peux modifier/supprimer mes demandes de congés

Default credentials - fresh install

Hello - what are the default credentials to login on a fresh install? Cheers, Dave

Update - figured it out:

curl --header "Content-Type: application/json"
--request POST
--data '{"email":"[email protected]","password":"john"}'
http://127.0.0.1:3000/api/login

btw: my client is running on port 3000.

It didn't seem to create the user ([email protected]) for me during the install - just a docker user:

permacoop=# select * from user;
user

docker
(1 row)

permacoop=# select * from user_administrative;
id | joiningDate | leavingDate | annualEarnings | transportFee | healthInsurance | executivePosition | contract
----+-------------+-------------+----------------+--------------+-----------------+-------------------+----------
(0 rows)

permacoop=# select * from customer;
id | name | createdAt | addressId
----+------+-----------+-----------
(0 rows)

ETQ que coopérateur et salarié, lorsque je supprime un évenement qui possède une exception de ticket restaurant je supprime mon exception

ETQ Salarié je vois apparaître les jours fériés sur mon faircalendar

Aujourd'hui les jours fériés n'apparaissent pas et quand on veut noter quelque chose sur un jour férié il est indiqué comme "non valide".

Ils doivent apparaître en grisé quand on est sur une vue du mois (comme les jours des mois précédents ou suivants) et être notés fériés.
Et quand on veut noter quelque chose sur un jour férié, il doit être indiqué : "vous ne pouvez pas saisir d'informations sur un jour férié."

ETQ que dev je souhaiterais déployer automatiquement mon application lors de chaque merge sur master

Actuellement (depuis #276), le déploiement de Permacoop se fait manuellement dans le terminal, en lançant make deploy env=prod.

Proposition

Modifier la conf GitHub Actions pour lancer le déploiement automatiquement lors d'un merge sur master.

Motivation

Avantages :

• Réduire la friction à la contribution : tout-e contributeur-ice pourra déployer en ayant sa PR mergée, sans avoir à faire le setup de déploiement décrit dans la documentation.

Risques :

• Le vault-password doit être stocké aussi en dehors de GitHub Actions. Il faut garder la possibilité de déployer ou intervenir manuellement.

Implémentation

• Générer des clés SSH pour GitHub Actions
• Les ajouter à ~/.ssh/known_hosts sur le serveur de prod
• Les ajouter en secrets dans GitHub Actions
• Configurer une deploy step qui les ajoute dans /.ssh/id_rsa(.pub), que Ansible utilisera lorsqu'on lancera cd ansible && make deploy env=prod.

Utiliser de l'I18n côté client

As a developer I'd like to use Svelte with TypeScript.

As a developer I enjoy when a "compilator" yell at me. I'd like to build my frontend with typescript since Svelte has an official support.

Source : https://svelte.dev/blog/svelte-and-typescript

Here is an example fully configured with typescript : https://github.com/babichjacob/sapper-typescript-graphql-template

We can forget about the graphql stuff from this repo because we don't use graphql but this project could be a source of inspiration

Fresh install fails

I just cloned a fresh install and I get the following when I do make install

osboxes@osboxes:~/permacoop$ sudo make install
cp server/ormconfig.json.dist server/ormconfig.json
cp server/.env.dist server/.env
cp client/config.js.dist client/config.js
docker run -it --rm -v /server:/app -w /app node npm i
npm WARN saveError ENOENT: no such file or directory, open '/app/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/app/package.json'
npm WARN app No description
npm WARN app No repository field.
npm WARN app No README data
npm WARN app No license field.

up to date in 0.421s
found 0 vulnerabilities

docker run -it --rm -v /client:/app -w /app node npm i
npm WARN saveError ENOENT: no such file or directory, open '/app/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/app/package.json'
npm WARN app No description
npm WARN app No repository field.
npm WARN app No README data
npm WARN app No license field.

up to date in 0.391s
found 0 vulnerabilities

make start
make[1]: Entering directory '/home/osboxes/permacoop'
docker-compose -p permacoop up -d
Creating permacoop_database_1 ... done
Creating permacoop_api_1 ... done
Creating permacoop_client_1 ... done
make[1]: Leaving directory '/home/osboxes/permacoop'
make api-build-dist
make[1]: Entering directory '/home/osboxes/permacoop'
docker-compose -p permacoop exec api npm run build
ERROR: No container found for api_1
Makefile:36: recipe for target 'api-build-dist' failed
make[1]: *** [api-build-dist] Error 1
make[1]: Leaving directory '/home/osboxes/permacoop'
Makefile:10: recipe for target 'install' failed
make: *** [install] Error 2

docker ps shows the database ok but the client and the api containers exit immediately. - Cheers, Dave

EPIC ETQ salarié je veux pouvoir saisir mes jours travaillés sans détailler les heures passées sur différents projets

Trop de complexité aujourd'hui pour le calcul des journées travaillées.

avoir un 1 pour déterminer qu'on a travaillé la journée complète plutôt que de détailler les heures facturées (ou pas)

[Bug] affichage de plus de 3 événements le jour en cours, avec thème dark

l'affichage est gris très clair sur blanc

ETQ Salarié je peux noter un pourcentage de réduction sur chacune des lignes du devis.

Quand je prépare un devis, je peux ajouter un taux de réduction en plus des quantités et du taux HT. Le taux de réduction doit être en pourcentage et être pris en compte dans le montant du devis final.
CF Devis sur zoho par exemple.

[Tech] As a developer I would like to ensure my frontend code is well tested at any time

Description du besoin

A l'heure actuelle, le frontend n'est pas du tout testé par des tests automatiques. Etant donné que c'est une partie non négligeable de l'application, il serait bien que cette partie le soit afin de s'assurer à chaque changement de code dans le frontend que tout fonctionne comme attendendu.

Proposition d'implémentation

Dans un premier temps, l'on pourrait adopter une stratégie smoke test et tester en e2e les fonctionalitées principales de Permacoop

Note: ça sous entendrait de lister les fonctionalitées principales.

Quels outil de test ?

Sur catalogage, @florimondmanca et moi utilisons Playwright qui est relativement similaire à Cypress

Après quasiment 1 an d'usage et après avoir utilisé Cypress dans le cadre d'un autre projet, je me dis que cet outil répondrait au besoin et pourrait correspondre au cahier des charges suivant

• API facilement utilisable pour un dev front habitué au JS et aux tests avec un runner type jest
• Possibilité de parralléliser l'execution de tests
• facilitée de selectionner et intéragir avec des éléments du DOM

EPIC - Plop

CRM like.

All the people we have met are listed here so that everyone has a vision of the bond that we have with them.

ETQ coopérateur et salarié, dans le fair calendar, quand je modifie un évenement je dois aussi être capable de signifier que je souhaite avoir ou pas un ticket restaurant pour celui-ci

[tech] Utiliser les aliases rollup pour simplifier les imports

Utiliser la lib https://www.npmjs.com/package/@rollup/plugin-alias

Error when trying to create "accountant" user

As a cooperator user, when I go on page /human_resources/users, and I try to create an accountant user, I get the following error:
Cannot destructure property 'role' of 'userDto.userAdministrative' as it is undefined.

As a developer I'd like to use storybook to dev my components in isolation

How to ? https://www.learnstorybook.com/intro-to-storybook/svelte/en/get-started/

Supprimer la partie fiche de paie

[Bug] Meal ticket removals store a wrong date

Description

La date envoyée par le front lors de l'enregistrement d'un meal_ticket_removal n'est pas bonne.

Impact

C'est problématique car le calcul des tickets resto consommés sera faux si on renseigne un ticket resto pour une journée d'un mois passé. Ça peut facilement se passer à la bordure d'un mois, par ex si on remplit un CRA le 1 ou 2 du mois pour une journée du 29 du mois d'avant.

Comportement attendu

La date est celle de l'événement auquel le retrait de ticket resto est associé (par ex : une journée de mission effectuée il y a 1 semaine)

Comportement réel

La date est la date actuelle (la date d'envoi du formulaire de CRA).

Comment reproduire

• Aller dans FairCRM
• Cliquer sur une date autre qu'aujourd'hui pour ajouter un CRA
• Cocher la case "Je ne souhaite pas recevoir de ticket resto" et remplir le commentaire
• Enregistrer le CRA
• Constater en BDD que la date enregistrée dans le nouveau meal_ticket_removal est celle d'aujourd'hui (plus précisément la date d'envoi du formulaire)

[TECH] As a developer I'd to know what are the a11y issues of the application

Lien epic #271

#Description du besoin

Sur l'epic #271, le constat que permacoop doit certainement présenter des problèmes d'accessibilités a été fait. Mais quels sont ces problèmes ?

Une première étape serait de soumettre permacoop a une forme d'audit pour les découvrir

Comment procéder pour identifier les problèmes potentiels ?

Approche automatique

Il existe des outils qui permettent d'auditer une application de manière automatique qu'ils soient utilisable en CLI ( axe core, ...) , sous forme d'extension navigateur (wave) ou autre.

Ces outils peuvent déja aider a comprendre certains problèmes d'a11y

Faire un audit manuel

Le RGAA propose une série de tests auxquels ont peut soummetre l'application pour mettre en lumière des choses à améliorer.

L'idée serait de réaliser un audit se basant sur ce référenciel.

Il existe d'autres check-list sur lesquels ont pourrait se baser :

• https://design.numerique.gouv.fr/outils/checklist-dev
• https://doc.incubateur.net/design/ressources-design/kit-accessibilite/accessibilite/10-choses-faciles-a-verifier-pour-un-site-plus-accessible

Passer par un auditeur externe

Des entreprises proposent des audit d'a11y, une approche serait de faire passer un audit externe a permacoop

Livrable attendu

• pour chaque page de permacoop, avoir une liste de choses à corriger

---

-- EDIT 17 février 2023 --

Un travail d'amélioration de l'a11y de catalogue.data.gouv sur lequel @julie-desvaux et moi même sont impliqué à été mené.

Cela a permisde plus clarifier la stratégie à adopter.

A l'heure actuelle, elle pourrait être résumée par veiller à ce que chaque fonctionalité migrée durant le chantier #321 soient accessible.

Par la suite, il faura certainement envisager un audit externe pour confirmer que permacoop est bien accessible

Sécurisation de l'api

• Implémentation api rate limit
• csp
• ...

ETQ dev je veux supprimer lodash \o/

Je ne sais pas pourquoi on se retrouve avec lodash, mais faut supprimer ce package !!!

Dev local : les tests unitaires API qui manipulent des dates échouent

Comportement attendu

En local, tous les tests lancés avec make test devraient passer, comme c'est le cas sur la CI

Comportement réel

On a 9 tests unitaires côté API qui échouent (côté client c'est OK).

Pour reproduire

• git checkout master
• make test-api

Pistes de résolution

Puisque ça concerne les tests qui manipulent des dates, c'est peut-être un problème de timezone pas définie (les serveurs de GitHub sont qq part dans le monde où les tests passent)

Debug

Sortie de make test :

 FAIL  src/Application/Common/MonthDate.spec.ts
  ● MonthDate › testFirstDayOfMonth

    expect(received).toBe(expected) // Object.is equality

    Expected: "2022-12-01"
    Received: "2022-11-30"

       5 |     const month = new MonthDate(2022, 12);
       6 |     const firstDay = month.getFirstDay();
    >  7 |     expect(firstDay.toISOString().substring(0, 10)).toBe('2022-12-01');
         |                                                     ^
       8 |   });
       9 |
      10 |   it('testLastDayOfMonth', async () => {

      at Object.<anonymous> (Application/Common/MonthDate.spec.ts:7:53)

  ● MonthDate › testLastDayOfMonth

    expect(received).toBe(expected) // Object.is equality

    Expected: "2022-12-31"
    Received: "2022-12-30"

      11 |     const month = new MonthDate(2022, 12);
      12 |     const lastDay = month.getLastDay();
    > 13 |     expect(lastDay.toISOString().substring(0, 10)).toBe('2022-12-31');
         |                                                    ^
      14 |   });
      15 | });
      16 |

      at Object.<anonymous> (Application/Common/MonthDate.spec.ts:13:52)

 PASS  src/Infrastructure/Common/Utils/Array.spec.ts
 PASS  src/Domain/File/File.entity.spec.ts
 PASS  src/Infrastructure/HumanResource/Leave/DTO/ModerationDTO.spec.ts
 PASS  src/Domain/Accounting/QuoteItem.entity.spec.ts
 PASS  src/Domain/Task/Task.entity.spec.ts
 PASS  src/Domain/HumanResource/Savings/InterestRate.entity.spec.ts

Summary of all failing tests
 FAIL  Application/HumanResource/Payslip/Query/GetUserElementsQueryHandler.spec.ts
  ● GetUserElementsQueryHandler › testGetUserElements

    expect(received).toMatchObject(expected)

    - Expected  - 6
    + Received  + 6

    @@ -1,7 +1,7 @@
      Array [
    -   UserElementsView {
    +   Object {
          "annualEarnings": 20000,
          "contract": "cdi",
          "exceptionalLeaves": UserLeavesView {
            "leaves": Array [],
            "totalDays": 0,
    @@ -11,22 +11,22 @@
          "isExecutivePosition": true,
          "joiningDate": "2022-11-04T10:05:03.143Z",
          "lastName": "Doe",
          "mealTickets": 5,
          "monthlyEarnings": 1666.6666666666667,
    -     "paidLeaves": UserLeavesView {
    +     "paidLeaves": Object {
            "leaves": Array [
              LeaveRequestSlotView {
                "endDate": "2022-05-11",
                "startDate": "2022-05-09",
              },
    -         LeaveRequestSlotView {
    +         Object {
                "endDate": "2022-05-02",
    -           "startDate": "2022-05-01T00:00:00.000Z",
    +           "startDate": "2022-04-30T22:00:00.000Z",
              },
    -         LeaveRequestSlotView {
    -           "endDate": "2022-05-31T00:00:00.000Z",
    +         Object {
    +           "endDate": "2022-05-30T22:00:00.000Z",
                "startDate": "2022-05-29",
              },
            ],
            "totalDays": 0,
          },

      143 |     const transportFee = rawTransportFee * 0.01;
      144 |
    > 145 |     expect(await queryHandler.execute(query)).toMatchObject([
          |                                               ^
      146 |       new UserElementsView(
      147 |         'John',
      148 |         'Doe',

      at Object.<anonymous> (Application/HumanResource/Payslip/Query/GetUserElementsQueryHandler.spec.ts:145:47)

 FAIL  Infrastructure/Adapter/DateUtilsAdapter.spec.ts
  ● DateUtilsAdapter › testGetWorkedDaysDuringAPeriod

    expect(received).toMatchObject(expected)

    - Expected  - 6
    + Received  + 8

      Array [
    -   2020-12-24T00:00:00.000Z,
    -   2020-12-28T00:00:00.000Z,
    -   2020-12-29T00:00:00.000Z,
    -   2020-12-30T00:00:00.000Z,
    -   2020-12-31T00:00:00.000Z,
    -   2021-01-04T00:00:00.000Z,
    +   2020-12-23T23:00:00.000Z,
    +   2020-12-24T23:00:00.000Z,
    +   2020-12-27T23:00:00.000Z,
    +   2020-12-28T23:00:00.000Z,
    +   2020-12-29T23:00:00.000Z,
    +   2020-12-30T23:00:00.000Z,
    +   2020-12-31T23:00:00.000Z,
    +   2021-01-03T23:00:00.000Z,
      ]

      64 |     expect(
      65 |       dateUtils.getWorkedDaysDuringAPeriod(startDate, endDate)
    > 66 |     ).toMatchObject([
         |       ^
      67 |       new Date('2020-12-24'),
      68 |       new Date('2020-12-28'),
      69 |       new Date('2020-12-29'),

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:66:7)

  ● DateUtilsAdapter › testGetWorkedFreeDays

    expect(received).toMatchObject(expected)

    - Expected  - 2
    + Received  + 2

    @@ -5,8 +5,8 @@
        2020-07-14T00:00:00.000Z,
        2020-08-15T00:00:00.000Z,
        2020-11-01T00:00:00.000Z,
        2020-11-11T00:00:00.000Z,
        2020-12-25T00:00:00.000Z,
    -   2020-04-13T00:00:00.000Z,
    -   2020-05-21T00:00:00.000Z,
    +   2020-04-12T22:00:00.000Z,
    +   2020-05-20T22:00:00.000Z,
      ]

      77 |     const dateUtils = new DateUtilsAdapter();
      78 |
    > 79 |     expect(dateUtils.getWorkedFreeDays(2020)).toMatchObject([
         |                                               ^
      80 |       new Date(`2020-01-01T00:00:00.000Z`),
      81 |       new Date(`2020-05-01T00:00:00.000Z`),
      82 |       new Date(`2020-05-08T00:00:00.000Z`),

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:79:47)

  ● DateUtilsAdapter › testGetEasterDate

    expect(received).toMatchObject(expected)

    Expected: 2020-04-12T00:00:00.000Z
    Received: 2020-04-11T22:00:00.000Z

      107 |     const dateUtils = new DateUtilsAdapter();
      108 |
    > 109 |     expect(dateUtils.getEasterDate(2020)).toMatchObject(
          |                                           ^
      110 |       new Date(`2020-04-12T00:00:00.000Z`)
      111 |     );
      112 |     expect(dateUtils.getEasterDate(2021)).toMatchObject(

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:109:43)

  ● DateUtilsAdapter › testGetLeaveDuration

    expect(received).toBe(expected) // Object.is equality

    Expected: 7
    Received: 8

      126 |     expect(
      127 |       dateUtils.getLeaveDuration('2020-05-05', false, '2020-05-15', false)
    > 128 |     ).toBe(7);
          |       ^
      129 |   });
      130 |
      131 |   it('testGetMinimumLeaveDuration', () => {

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:128:7)

  ● DateUtilsAdapter › testGetLastDayOfYear

    expect(received).toStrictEqual(expected) // deep equality

    Expected: 2021-12-31T00:00:00.000Z
    Received: 2021-12-30T23:00:00.000Z

      147 |     const now = new Date('2021-12-12');
      148 |     const result = dateUtils.getLastDayOfYear(now);
    > 149 |     expect(result).toStrictEqual(new Date('2021-12-31'));
          |                    ^
      150 |   });
      151 |
      152 |   it('getFirstDayOfYear', () => {

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:149:20)

  ● DateUtilsAdapter › getFirstDayOfYear

    expect(received).toStrictEqual(expected) // deep equality

    Expected: 2021-01-01T00:00:00.000Z
    Received: 2020-12-31T23:00:00.000Z

      154 |     const now = new Date('2021-12-12');
      155 |     const result = dateUtils.getFirstDayOfYear(now);
    > 156 |     expect(result).toStrictEqual(new Date('2021-01-01'));
          |                    ^
      157 |   });
      158 |
      159 |   it('getMonth', () => {

      at Object.<anonymous> (Infrastructure/Adapter/DateUtilsAdapter.spec.ts:156:20)

 FAIL  Application/Common/MonthDate.spec.ts
  ● MonthDate › testFirstDayOfMonth

    expect(received).toBe(expected) // Object.is equality

    Expected: "2022-12-01"
    Received: "2022-11-30"

       5 |     const month = new MonthDate(2022, 12);
       6 |     const firstDay = month.getFirstDay();
    >  7 |     expect(firstDay.toISOString().substring(0, 10)).toBe('2022-12-01');
         |                                                     ^
       8 |   });
       9 |
      10 |   it('testLastDayOfMonth', async () => {

      at Object.<anonymous> (Application/Common/MonthDate.spec.ts:7:53)

  ● MonthDate › testLastDayOfMonth

    expect(received).toBe(expected) // Object.is equality

    Expected: "2022-12-31"
    Received: "2022-12-30"

      11 |     const month = new MonthDate(2022, 12);
      12 |     const lastDay = month.getLastDay();
    > 13 |     expect(lastDay.toISOString().substring(0, 10)).toBe('2022-12-31');
         |                                                    ^
      14 |   });
      15 | });
      16 |

      at Object.<anonymous> (Application/Common/MonthDate.spec.ts:13:52)


Test Suites: 3 failed, 120 passed, 123 total
Tests:       9 failed, 285 passed, 294 total
Snapshots:   0 total
Time:        25.719s
Ran all test suites

ETQ coopérateur je peux voir un récapitulif du nombre de ticket restaurant dont je dispose par mois

Suivi de la trésorerie

Idée :

• On a les infos sur les encaissements via FairCRM (calendar, projets, missions)
• On a les ifnos sur les salaires
• On peut rajouter des charges fixes (EDF, assurances, ...)

=> On utilise ces infos pour :

• Estimation des encaissements mensuels
• Estimation de la facturation mensuelle
• Calculer le surplus mensuel : "en rythme de croisière (on est payé l'équivalent de ce qu'on facture), est-ce qu'on gagne / perd de l'argent ce mois-ci ?"
• Faire des graphiques de tout ça
• Outils de prévisionnel : peut-on supporter le salaire de X personnes sans mission pendant Y mois ?

... Est-ce que ça reviendrait à brancher Permacoop sur scopyleft/simulation

ETQ salarié j'ai le nombre de tickets restaurant qui correspondent au nombre de jours travaillés.

EPIC à poser pour discuter de la règle de calcul du notre de tickets resto.
Aujourd'hui le calcul est basé sur le temps saisi et donc une addition.
Possibilité de partir du nombre de jours ouvrés et décompter les jours qui ne demandent pas de tickets resto.

Migrer les fichiers stockés sur S3 (fiche de paie)

ETQ salarié-e je peux visualiser les congés de l'équipe dans mon calendrier afin de se coordonner

Idée remontée via @Volubyl et @julie-desvaux

User story

ETQ salarié-e j'ai besoin de connaître les congés de l'équipe afin de savoir quand les collègues sont absents

Critères d'acceptation

• La page Congés permet de récupérer un lien d'inscription au calendrier des congés
• L'import dans ProtonCalendar avec ce lien fonctionne
• L'import dans Thunderbird avec ce lien fonctionne
• Le calendrier contient les congés de tout le monde
• Le calendrier contient les congés passés et futurs
• Le calendrier ne contient PAS les congés des salariés partis de Fairness
• Les événements de calendrier permettent de distinguer qui est en congés
• Les congés s'affichent en événements "Toute la journée" prenant toute la plage d'un congé
• L'URL de calendrier est difficile à deviner de l'extérieur

Design

Un bouton permettra de copier un lien de souscription, exposé par le serveur à l'URL suivante :

GET /api/leaves/export?cal_id=<cal_id>

Le <cal_id> est traité comme un secret. Il permet de sécuriser l'endpoint un minimum. En effet cette URL doit être publique pour que les clients de calendrier puissent y souscrire. Il faut un équivalent du bouton "Copier le lien de souscription" dans Framagenda.

Le contenu est un flux iCalendar tel que défini par le standard iCalendar - RFC 5545. En bref, il s'agit d'une string contenant un VCALENDAR et autant de VEVENT que de congés.

Implémentation

• Endpoint API #287
• Bouton dans l'UI #325

ETQ Comptable je peux accéder au tableau récap Paie du mois.

Tableau récapitulatif avec, pour chaque salarié:

• NOM
• Prénom
• Matricule
• Type de contrat
• Date d'entrée dans la coopérative
• Salaire Brut annuel
• Salaire Brut Mensuel
• Temps Partiel ou Temps Complet
• Montant de l'abonnement mensuel de transport
• Nombre de tickets resto à donner
• Abonnement à la Mutuelle (Oui/Non)
• Nombre de jours de Congés Payés
• Date de début/ Date de fin --> Possibilité d'avoir plusieurs périodes distinctes de congés sur le mois
• Nombre de congés exceptionnels (avec les dates)
• Nombre de jours arrêt maladie (avec les dates)
• Nombre de jours de congés sans solde
• Case commentaires pour toute communication nécessaire entre les RH et la Paie

Migrer sur tailwindcss

ETQDev je souhaite avoir une commande pour analyser le poids du bundle généré.

Utiliser source-map-explorer pour pouvoir identifier les optimisations à réaliser.

Suivi de la participation / épargne salariale

L'objectif est d'avoir un suivi des "comptes bloqués" des coopérateurs/salariés dans le cadre de l'accord de participation.

Vues

Vue tableau : pour chaque utilisateur :

• Nom, prénom
• Solde (somme des crédits et des débits)
• Voir les détails

Vue détail : pour chaque opération sur le compte bloqué :

• Date
• Personne qui a effectué l'opération
• Montant (positif si crédit, négatif si débit)

Contexte additionnel

Hélène a mentionné le fait que coop tech avait un outil similaire, dont on pourrait potentiellement s'inspirer. L'objectif de permacoop est d'avoir un outil qui centralise tout ce dont on a besoin au bon fonctionnement de la coopérative et d'en faire une vitrine tech/produit.

ETQ dev je voudrais avoir un outil type Sentry

[Tech] Refonte du front-end de Permacoop

Refonte du front-end de Permacoop

Etat des lieux

Sapper est devenu obsolète

Actuellement, le front-end de permacoop est construit avec les technologies suivantes :

• Le framework Sapper
• Svelte
• Tailwind pour la gestion du CSS

Le développement de Sapper a été arreté en faveur d'un "nouveau" framework nommé Sveltekit

Comme l'indique le Doc de Sapper

Sapper's succesor, is currently available for use. All development efforts moving forward will be focused on .

Sapper est en "maintenance" mais plus aucune fonctionalité sera rajoutée. De ce fait, il est certainement temps de migrer vers SvelteKit

Le frontend n'est pas testé

Contrairement au back-end qui possède une bonne couverture de tests, le front-end, lui n'est pas du tout tester via des tests automatiques qu'ils soient unitaires ou end-to-end

Ce type de test pourrait permettre de garantir le bon fonctionement de la partie front-end de l'application

Nous ne pouvons pas garantir que permacoop est accessible

Fairness s'insert dans l'écosystème du "Numérique responsable".

De ce fait nous souhaitons que les applications produite par la coopérative en respecte les principes.

Le numérique responsable inclut un volet visant à ne pas exclure certaines populations :

"celles peu à l’aise avec les technologies numériques, celles habitant en zone blanche, celles avec une faible connexion ou encore celles ayant un handicap. Il s’agit donc de tendre vers des services publics numériques inclusifs : des services accessibles"

source

Vérifier que Permacoop est accessible (au sens RGAA du terme) permettrait de voir si cette application est conforme aux attentes Fairness.

Nous ne pouvons pas expliquer pourquoi permacoop est éco-concu

Comme dit dans le paragrpahe précédent, Fairness se revendique du "Numérique responsable".

Le numérique responsable inclut aussi une volonté de "Réduire l’impact environnemental" du numérique

Permacoop a été construit sur des pratiques d'éco-conception mais actuellement rien ne permet de le prouver/ démontrer.

Description du besoin et pistes de remédiations possibles

Face à ces constats, je propose de mener un chantier de "remédiation" afin de pouvoir améliorer le frontend de Permacoop.

Ce chantier peut être vu comme un "milestone" (au sens Github du terme)

⚠️ ce paragraphe vise à proposer de manières succintes des pistes de remédiations. Il est fort probable que chacune de ces pistes fera l'objet d'une isssue dédiée. Dans quel cas, chacune de ces issues sera décrite et analysée plus en profondeur.

Axe : Migration depuis Sapper vers SvelteKit

• #214

Une piste pour remédier à cela sera de migrer tout le frontend depuis Sapper vers Svelte kit et l'on pourrait aussi en profiter pour mettre à jour les dépendences du projet.

Je pense que dans un premier temps, l'on pourrait chercher à être simplement "iso-fonctionnel", c'est à dire faire en sorte que la version avec SvelteKit présente les mêmes fonctionalitées que la version avec Sapper.

Cela implique de veiller a ce que rien ne soit rajouter ou manquant après avoir effectuer la migration.

Axe: Tester le frontend

• #272

L'idée de cet axe est de pouvoir garantir de manière automatique que le frontend de l'application (et plus largement l'application elle-même) garde un haut niveau de qualité logicielle

Les tests automatiques sont un bon moyen de le garantir.

En vue du travail à effectuer pour l'"Axe Obsolescence de Sapper", les tests e2e pourraient être un bon outil pour inventorier les fonctionalités de l'application et garantir que l'on reste bien "iso-fonctionnel"

Dans un second temps, on pourrait aussi a améliorer la couverture de test via des tests untaires en cherchant a tester aussi bien les fonctions "utilitaires" que les composants.

Axe : Garantir que Permaccop est accessible

Ici dans un premier temps, mon idée serait de faire un audit de l'application pour déterminer la conformité au RGAA

:question-mark: Pourquoi le RGAA ? En France, le RGAA est le référenciel recommandé par l'Etat Français

Je pense que dans un premier temps, l'on pourrait se baser sur les beta.gouv et sur les tests proposés par le RGAA pour effectuer cet audit et le cas échéant essayer d'améliorer la situation.

En fin de course, soumettre Permacoop à un audit externe pourrait aussi être une bonne chose.

Pour moi le livrable serait, l'ajout d'une déclaration d'accessibilité à Permaccop

Axe : Expliquer pourquoi permacoop est éco-concu

Je crois sincèrement que Permacoop a été conçu en gardant les 115 bonnes pratiques en ligne de mire mais qu'est-ce qui le prouve aux personnes voulant utiliser permacoop ?

Pour moi cet axe aurait pour objectif de trouver un moyen pour expliquer en quoi Permacoop est éco-conçu.

ETQ salarié je peux avoir un montant de frais de transports à 0.

Aujourd'hui, les frais de transports doivent forcément être à un montant positif. Je voudrais qu'on puisse, OU NON, demander un remboursement de frais de transports.