Particularités non portées sur la v2 et existantes en v1
Merle
Marbré
Stippel
Manx
Golden
Silvermane
Black Eyed (auto porté avec la couleur des yeux + la couleur du rat)

Dilutions
Ivory (j'imagine que c'est "auto porté" avec l'albinos aux yeux noirs)

Tu veux que je traite ça comment ?

Mais renvoie BITE$$$!

La doc invite actuellement à merger directement dans le master les branches "perso" stables apportant une nouvelle fonctionnalité, mais ne serait-il pas mieux d'inciter à passer par des pull requests ? (qui permettent de garder + de doc sur la fonctionnalité apportée, et que la branche soumis soit relue et validée par quelqu'un d'autre que son auteur ?)

Je dis ça alors que je viens de merger (sans réfléchir), mais il aurait été sûrement mieux que je fasse une pull request pour vous informer de ce qu'apporte mon dernier merge. Est-ce qu'on adopte une politique plus stricte "ne mergez pas sur le master, faites une pull request" ?

Doc générale : https://www.php.net/manual/fr/book.image.php

A noter qu'il faut utiliser obligatoirement la/les fonction/s header('Content-Type: image/jpeg'); avec les bons types d'images si on veut pouvoir les afficher (une petite liste déjà rédigée sur developpez.com)

• Création d'une ressource d'image (pour charger l'image à redimensionner) : imagecreatefromstring() --> détecte automatiquement le type d'image et retourne false si le type est invalide
• Taille d'une image (taille de l'image à redimensionner) : getimagesize() --> retourne un tableau, [0]=>width, [1]=>height
• Création d'une nouvelle image "vierge" (pour créer l'image redimensionnée) : imagecreatetruecolor()
• Redimensionnement d'une image (recopie l'image de départ dans l'image vierge précédemment créée, avec la nouvelle taille) : imagecopyresampled() --> l'exemple 1 est à voir
• Libère la mémoire : imagedestroy()

Peut être utile :

• Extension d'une image : image_type_to_extension()
• Un tuto pas très propre mais super léger qui permet de voir un peu le principe et l'enchaînement des fonctions pour redimensionner une image

Info needed.

Déterminer comment nous stockons les caractères spéciaux en base afin qu'ils soient correctement restitués.
Actuellement, y a de tout, parce qu'il y avait de tout dans le lord v1

Y a des apostrophes stockées en clair et des apostrophes converties en '

Je ne sais pas ce qui convient le mieux, le tout étant d'être coordonnés sur l'encodage/décodage et après je ferais de mon mieux pour les stocker convenablement

J'avais déjà remonté le sujet mais je le reposte ici proprement pour qu'on ne l'oublie pas.

Le Lord v1 était sensible à la casse et aux accents pour les noms d'utilisateur, on a donc des pseudos qui se ressemblent mais qui ne sont pas forcément des doublons.

Akuma (en conflit avec Akumã)
stephy (en conflit avec Stéphy)
back' (doublon de Back') -> vrai doublon
Anaïs (en conflit avec anais)
meli (en conflit avec Méli)
Chimère (en conflit avec chimere)
Melanie (en conflit avec Mélanie)
Cundolë (doublon de Cundole) -> vrai doublon
Léa (en conflit avec Lea)

Vous avez une suggestion pour traiter ça ?
Est-ce qu'on se dit qu'on verra post migration pour rattacher les rats "manuellement" à leur propriétaire ? (actuellement, si le rat n'a pas de propriétaire identifié dans cakelord, je le rattache à LORD pour le migrer quand même).
Etant donné que le lord v1 n'est pas vraiment une base relationnelle, je fais les rapprochements des propriétaires sur leur nom, donc un renommage pré migration est délicat à gérer (mais pas impossible non plus)

4 portées migrées alors qu'elles ne devraient pas pouvoir l'être :
#3271
#3391
#4674
#5493

(Créent un bug pour toute action individuelle, mais apparaissent dans l'index.)

A voir s'il faut les supprimer ou repêcher les infos.

Rats Devil + marbré
FGI41439M à passer en devil (ses deux parents sont devil donc il ne peut pas être burmese.) --> normalement OK avec la migration, à vérifier
LAD34570M à passer en devil (pas de burmese dans la généalogie.) --> normalement OK avec la migration, à vérifier
MEZ29790F à passer en burmese marbré pointé, au vu de la généalogie c'est le plus crédible.
DTC49584M --> à passer en burmese marbré, pointé ou pas je sais pas par contre (en attente de réponse de Limë)

Have to figure out how to make it work in Entity/Rat.php

In rat model (wrapFamilyStatistics), ascendants and descendants statistics include the rat itself, resulting in:

• bad count of ascendants and descendants
• statistics provided for rat which haven't known ascendants/descendants

Removing one unit in the count doesn't solve the latter issue, a better fix is needed.

Texts to convert :

• Rats comments (peel_rats ; comment --> rats ; comments)
• SAV comments (peel_rats ; sav --> messages ; content)
• Ratteries comments (peel_marques ; description_fr --> ratteries ; comments)

HTML tags to markdown

• <strong>bold text</strong> --> **bold text**
• <br> -->
• <em>italic text</em> --> *italic text*
• <ins>italic text</ins> --> *italic text*
• <ul></ul> --> nothing
• <li>item 1</li> --> - item 1
• <a href="URL">text</a> --> [Text](URL)

Prévoir un champ ancien mot de passe / nouveau mot de passe dans la base
Prévoir une routine de changement de mot de passe à la première connexion des anciens users

When triggering micro-actions like transferring ownership, relocating rattery, declaring rat death etc. a "back" button to return to the entity sheet is sometimes available, sometimes isn't. To be homogeneized when all micro-actions are done.

La couleur actuellement choisie pour les titres (mauve/lavande) n'est pas assez contrastée sur fond blanc pour respecter les normes d'accessibilité visuelle.

Outil pour tester le respect des normes de contraste : https://webaim.org/resources/contrastchecker/
Outil pour établir des palettes sans trop tâtonner : https://color.adobe.com/fr/create

NB. De manière générale il faudra vérifier à terme d'autres critères d'accessibilité (webaim semble offrir plein de bons conseils, ressources et outils pour ça), à voir plus tard si on garde sur ce ticket ou si on en ouvre un autre.

Compte tenu du nombre très élevé de rats rattachés aux rateries génériques en particulier INC et IND, la vue d'une telle raterie est impossible (crash mémoire). La liste des rats attachés devrait être exclue de ces vues.

Le jeu de données de test assigne les identifiants numériques les plus bas aux comptes génériques (users LORD, ratteries INC IND etc.,... ).

Ces comptes devraient être exclus des données de migration. Les comptes migrés obtiendront un nouvel identifiant numérique via le biais de l'auto-incrémentation. Les champs de jointure doivent tenir compte de cette modification pour assigner la bonne valeur aux clés étrangères.

Add a rule to verify that the rat->rattery_id is the same as the rat->birth_litter->contributions[0]->rattery_id (if it exists)

La soumission d'un formulaire éditant un rat (transfert de propriété, déclaration de décès, etc.) déclenche une erreur :

Argument 1 passed to Cake\Chronos\Date::equals() must implement interface Cake\Chronos\ChronosInterface, null given, called in /home/artefact/www/CakeLORD/src/Model/Entity/Rat.php on line 202

Le code correspondant sert à vérifier si la date de naissance a été modifiée (utilisé dans le Behavior "Snapshot")

public function hasUnchangedBirthDate() { return $this->birth_date->equals($this->_original['birth_date']); }

On constate qu'un dd($this->_original) avant le return renvoie effectivement un tableau vide.

When people only remember their username, offer a functionality to display a hint about the registration email, of the form : gl*******a@g****.com

Les fonctions de recherche ne tiennent actuellement pas compte de la propriété is_searchable liée à l'état de la fiche, et renvoient donc des résultats qui ne devraient pas l'être.

Nouveautés login

• le login n'est pas permis si le compte est verrouillé (message "votre compte est verrouillé")
• mise à 0 de failed_login_attempts et à null de failed_login_last_date lors d'un login réussi
• incrément de failed_login_attempts et mise à now() de failed_login_last date lors d'un login raté sur un username existant
• si failed_login_attempts > 5 et failed_login_last_date postérieure à (maintenant - 15 minutes), le login échoue et l'utilisateur est invité à attendre 15 minutes avant de réessayer de se connecter (compte comme un login raté, maj des variables idem)

Nouveautés récup mot de passe

• l'utilisateur peut demander à recevoir un lien unique de régénération de mot de passe, par mail, en visitant /users/lostPassword et en saisissant son adresse mail
• si adresse mail trouvée, création et écriture d'une passkey dans la table users et mise à jour des failed_login_attempts et last_date (compte comme un login raté)
• le mail est faussement envoyé - mais visible dans debugKit (il faudra décider de la méthode d'envoi de mail sur la future prod) ce qui permet de récupérer la passkey sans aller dans le SQL
• l'utilisateur peut réinitialiser son mot de passe en visitant le lien envoyé dans les 24 heures (/users/reset-password/$passkey). Le mot de passe est mis à jour. Pas de maj des variables de login raté (seront mises à jour au premier login avec le nouveau mot de passe)
• sinon échec et il est invité à renouveler sa demande.

La table States est encore à l'état de squelette mais nous allons bientôt entamer le workflow, les changements d'états et les messages. Pour cela, les comportements associés à un état doivent être définis.

J'envisage les propriétés suivantes (tous ces champs sont booléens) :

• needs_user_action
• needs_staff_action
• is_fit_for_stats
• is_visible
• is_searchable (peut apparaître avec une recherche explicite même si ! is_visible)
• is_frozen (données gelées qui ne doivent plus être modifiées)

D'autres idées de propriétés utiles ?

Cf. commentaire sur la pull request #61

Hello :)

Pour pouvoir tester la migration plus simplement, est-ce qu'il est possible d'avoir une "vue" des objets au SAV ? (statut_id = 2)
Dans l'ordre d'importance pour moi :

• rats
• litters
• ratteries

C'est pas super urgent non plus parce que je peux me débrouiller avec ce qui est dispo actuellement et des requêtes SQL, c'est juste pour gagner du temps

Artefact m'a dit que je pouvais demander ce dont j'avais besoin, alors je demande !

A user failing to register because his email or username already exists get a generic error message ("something went wrong"). We should be more explicit, but this may be fixed at field filling with a javascript check.

mettre le propriétaire pour les affixes génériques / à propriétaire générique, le propriétaire de la raterie de naissance si rat avec affixe "normal", idéalement. C'est ce qui permettrait d'avoir d'emblée la feature "la raterie peut éditer la fiche d'un adoptant"

bug introduced in commit 43b9116e.

Revert to uploads/img.

Probablement un "contain" qui manque dans le contrôleur associé pour construire le nom complet de la portée.

Création d'un champ booléen "wants_stats" dans la table ratteries.
Not null, "true" par défaut.

Certains utilisateurs ont en V1 un champ "email" qui n'est pas une adresse email. Exemple : user id 17 (louve, adresse mail : louve)

La migration se fait, mais si on veut éditer ces utilisateurs, on ne peut pas les sauvegarder (le validateur de la V2 vérifie que c'est une adresse mail et donc refuse.)

J'ai l'impression qu'il s'agit d'utilisateurs créés en V0 (sur le registre). Pour tous ceux que j'ai vus, email = username (sauf pour le user #25 qui est un cas particulier pour lequel je vais faire un autre ticket.)

Je ne sais pas comment traiter le problème, sachant que l'email doit être unique (on ne peut donc pas juste créer une adresse mail commune "[email protected]")

L'apparence des formulaires est de bric et de broc au gré des imports de javascript pour le front-end. Le javascript lui-même est inhomogène et éparpillé dans les templates. Prévoir une passe de nettoyage.

En combination avec la pull request #111 la table Roles doit être amendée comme suit :

• ajout de propriétés booléennes : can_describe, can_document, can_access_personal (null interdit, valeur par défault = 0)
• création d'un rôle Volunteer
• initialisation des valeurs :

When performing a new search from a rat advanced search results page, rattery_id is not fetched again - while rattery_name is reloaded in the form, leading to incoherent results.

Check rat add form management for correction (this is dealt with, when form is reloaded after rules checking failure).

Pour faciliter les statistiques prévues et préserver la généricité du code, besoin d'un champ booléen "is_tumor" dans la table des causes de décès secondaires, à positionner à "true" pour les causes :

· 4.9. Tumeur digestive (estomac, foie, pancréas, intestins. . . )
· 6.3. Tumeur musculaire
· 6.4. Tumeur osseuse
· 7.5. Tumeur cérébrale
· 7.6. Tumeur hypophysaire (pituitaire)
· 8.7. Tumeur de la glande de Zymbal
· 8.8. Tumeur de la face (hors Zymbal)
· 8.9. Tumeur rétro-orbitaire
· 9.4. Tumeur cutanée, cancer de la peau
· 10.3. Tumeur pulmonaire
· 11.4. Tumeur mammaire
· 11.5. Tumeur ovarienne
· 11.6. Tumeur utérine
· 11.7. Tumeur vaginale
· 11.8. Tumeur de la prostate
· 11.9. Tumeur testiculaire
· 11.10. Tumeur des glandes préputiales
· 12.4. Tumeur de la vessie
· 12.5. Tumeur du rein
· 14.2. Cancer généralisé, leucémie, lymphome
· 14.8. Tumeur autre (salivaire, splénique, surrénale, thyroïde...)
· 14.9. Tumeur indéterminée (organe atteint inconnu)

et à "false" pour toutes les autres.

1. Traitement des rats ayant une cause de décès mais pas de date de décès :

Si la cause est "Inconnue" (actuellement converti en "Cause indéterminée (date connue)"), la changer en "Aucune information" (converti en "Aucune information (présumé mort)"), ce qui évite d'avoir à les migrer en statut 5.

(Je ne sais pas s'il vaut mieux changer la cause en V1, puis migrer, ou migrer puis changer la cause en V2. Si jamais, en V2, cela correspond à : death_primary_cause_id = 1, death_secondary_cause_id = 1 et non 2).

2. Récupération automatique d'informations de décès dans les commentaires

Il me semble que l'on peut récupérer facilement la cause "Abcès dentaire" (primary: 8, secondary: 44) actuellement migrée en abcès indéterminé, et peut-être "Malocclusion" ?

Par ailleurs j'ai pu corriger plein de cas "cause de décès mais pas de date" car la date était dans les commentaires mais pas dans le champ, peut-être essayer de chercher "date de décès" ou "date du décès" ou "décédé le" dans les commentaires ?

Must find a way to circumvent state workflow when applying a snapshot for restoration.

In src/Controller/UsersController, method login()

Need to add update of fields : failed_login_attempts, failed_login_last_date
=> Null when success, +1 and now() respectively when failed login

Pour le stockage des signalements via le bouton "report" (que l'on va finalement garder séparer des conversations et messages) il faudrait créer une nouvelle table "issues" avec les champs suivants :

• id (clef primaire, autoincrément)
• is_open (booléen)
• url (varchar)
• complaint (texte)
• handling (texte)
• from_user_id (foreign key vers table users)
• closing_user_id (foreign key relation vers table users)
• created (datetime)
• closed (datetime)

Peuvent être vides : handling, closing_user_id et closed.

Pour la carte des rateries, deux champs ont besoin d'être ajoutés à la table ratteries dans le schéma de base : champs 'lat' et 'lng', tous les deux DECIMAL(10,7).

Besoin également de réexporter le svg pour la doc (docs/sql/cakelord.svg)

Problem: PictureBehavior assumes that the field to store the picture path is named "picture" in the model, but user's picture is named "avatar". For this reason, new avatar upload is not working.

Fix: Behavior should be modified to accept an optional parameter with field name (with default: "picture").

Le fait de qualifier les contributions fait que la table RatteriesLitters ne peut être considérée comme une simple table de jointure et l'absence de clé primaire simple complique quelque peu les choses : il devient difficile par exemple d'éditer une contribution. On n'a en fait aucun mécanisme simple pour définir le type de contribution à la création non plus.

Je propose donc les modifications suivantes au schéma de la base de données :

• La table litters_contributions devient contribution_types
• La table ratteries_litters est renommée Contributions
• Un champ id lui est ajouté en clé primaire auto-incrémentée unsigned int
• le champ litters_contribution_id devient contribution_type_id

@PetitangePA : Est-ce ok de ton côté ?

Environ 250 rateries ont "0000" comme année de création.
Je propose de modifier :

• Version simple mais acceptable : définir une année de création par défaut, à choisir entre nous (2006 pour la création du registre par exemple)
• Version mieux mais avec plus de boulot : attribuer l'année de création de la première portée de cette raterie, ou l'année d'enregistrement du compte utilisateur du propriétaire

Contributions' finder for ordering results should operate on RatteriesLitters rather than LittersContributions. Any contribution contain should be done through RatteriesLitters.

On rat global statistics : current display assumes that there are alive rats in all bins. As a result, ticks might be unaligned with tooltip if some bins are empty, and empty bins are not displayed, which is not the desired behavior.

La raterie n°9 avait pour affixe "BOFH" dans la base testlord.sql
A été tronquée à "BOF" avec les derniers changements.
L'édition de la raterie pour rétablir l'affixe BOFH renvoie une erreur SQL :

SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'prefix' at row 1.

En V1 l'utilisateur Indépendant a l'id #25. C'est redondant avec l'utilisateur #2 Unregistered défini dans les spécifications. Je propose de détruire le #25 et d'attribuer tout ce qui lui appartient au #2.

Je créé ce post pour lister les erreurs à corriger sur la base du lord v1 avant la migration, ce sont des erreurs qui ne valent pas la peine d'être traitées dans les scripts de migration parce que ça prend qqs secondes à corriger directement en base (très peu de rats concernés).

• Rats couleur "Lavende" et "Lavende agouti" à corriger en "Lavande" et "Lavande agouti"
• Rat dilution "burmese sable siamois" à corriger en "Burmese sable siamois"

Ajouter une case à cocher "j'accepte les conditions générales d'utilisation" (avec lien vers icelles) dans le formulaire d'inscription. Faire échouer l'inscription si case non cochée.

BredLitters should eager load OffspringRats rather than ParentRats.