fairnesscoop / permacoop Goto Github PK
View Code? Open in Web Editor NEWOpen source and eco-designed ERP solution for worker-owned businesses.
License: MIT License
Open source and eco-designed ERP solution for worker-owned businesses.
License: MIT License
Actuellement, le front-end de permacoop est construit avec les technologies suivantes :
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
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
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"
Vérifier que Permacoop est accessible (au sens RGAA du terme) permettrait de voir si cette application est conforme aux attentes Fairness.
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.
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)
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.
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.
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
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.
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
For reference this is the offical eslint configuration for nest
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.
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
http://localhost:3001/api/login
dans la console webIdées de résolution
Visiblement le front se parle à lui-même et pas à l'API
Le pb est probablement dans client/config.js
Tableau récapitulatif avec, pour chaque salarié:
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.
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
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
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 :
Des entreprises proposent des audit d'a11y, une approche serait de faire passer un audit externe a permacoop
-- 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
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é."
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.
L'objectif est d'avoir un suivi des "comptes bloqués" des coopérateurs/salariés dans le cadre de l'accord de participation.
Vue tableau : pour chaque utilisateur :
Vue détail : pour chaque opération sur le compte bloqué :
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.
Contexte*
Un salarié peut prendre des congés mais ceux-ci doivent être accepté par un autre salarié.
User stories
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.
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.
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
Thoughts?
Plus sérieusement, voici mon raisonnement...
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.
Retirer de docker-compose.yml les services suivants :
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
.
La date
envoyée par le front lors de l'enregistrement d'un meal_ticket_removal
n'est pas bonne.
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.
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)
La date
est la date actuelle (la date d'envoi du formulaire de CRA).
date
enregistrée dans le nouveau meal_ticket_removal
est celle d'aujourd'hui (plus précisément la date d'envoi du formulaire)Idée remontée via @Volubyl et @julie-desvaux
ETQ salarié-e j'ai besoin de connaître les congés de l'équipe afin de savoir quand les collègues sont absents
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.
Passer sur la nouvelle version de fullcalendar + appels api géré par le plugin.
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 :
Risques :
Implémentation
~/.ssh/known_hosts
sur le serveur de prod/.ssh/id_rsa(.pub)
, que Ansible utilisera lorsqu'on lancera cd ansible && make deploy env=prod
.client/kit
, sans régression à signaler.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).
client/kit
et client/legacy
soient utilisés en cohabitation.client/kit
.client/kit
. Autrement dit, client/legacy
est "gelé".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 |
|
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 |
|
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 |
|
Risques |
|
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 |
|
Risques |
|
Actuellement, le front-end de permacoop est construit avec les technologies suivantes :
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
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.
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
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
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
TODO: reformuler sous la forme "ETQ"
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.
Intégrer une fonction registre du personnel à Permacoop, sous la section "FairRH > Coopérateurs - Salariés".
Idéalement, il faut :
Pour cela, plusieurs options :
Les champs du registre sont actuellement :
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 ?
On pourrait les définir dans une section "Informations complémentaires pour le registre du personnel".
Je ne sais pas pourquoi on se retrouve avec lodash, mais faut supprimer ce package !!!
Utiliser source-map-explorer pour pouvoir identifier les optimisations à réaliser.
Hi, can anyone use this project? What do you mean by reserved for worker-owned business?
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.
Contexte :
En tant que salarié, j'ai besoin de pouvoir enregistrer ce que j'ai fait dans ma journée.
User stories :
Note :
Une entreprise possède plusieurs projets. Chaque projet peut avoir une durée de journée de travail différente.
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:
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)
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
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)
Utiliser la lib https://www.npmjs.com/package/@rollup/plugin-alias
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
Idée :
=> On utilise ces infos pour :
... Est-ce que ça reviendrait à brancher Permacoop sur scopyleft/simulation
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.
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:
Et donc finalement le nombre de tickets resto qui lui seront donnés à la fin du mois et leur valeur.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.