memphis-tools / oc_projet12_backend_securise_avec_django_orm Goto Github PK

Traduire le wiki complètement, en anglais.

Il faut que des factures puissent être réalisées lorsqu'un contrat est conclu.

Un contrat peut être signé, non signé, ou annulé.
Il faut demander si un contrat annulé peut être "réactivé".
Si un contrat annulé doit le demeurer, il faut verrouiller toute mise à jour.
Il faut demander si un contrat signé peut voir le montant évoluer ou s'il est ferme.

Faire comme pour le modèle contrat. avec la récupération du commercial à partir du client.
Ne pas utiliser la clef étrangère du client: il faut récupérer la référence au client depuis le Contrat.

Concerne tout export de données de l'application.

En cas de création d'un nouveau service dans l'entreprise, il faut permettre de pouvoir spéficier les permissions.
C'est le service Gestion qui peut ajouter /modifier /supprimer des collaborateurs.
On doit faire en sorte qu'en cas de création d'un service, il faut des droits spécifiques (en plus du Select, que tout collaborateur possède).

Permettre de ré-initialiser une base de données spécifique.
L'admin de l'application devrait pouvoir ré-initialiser une des bases, exclusivement, pas toutes à la fois.

Concerne les ajouts d'entreprise
Concerne aussi potentiellement l'ajout de client. Celui-ci référence une entreprise.
Lors de la création d'un client on réclame un "company_id" (un custom id d'une entreprise).
On veut pouvoir proposer de trouver la localité, en cas d'ajout d'une entreprise, après avoir saisi un SIREN et NIC.
Cette fonctionnalité demande un accès internet (variable settings.INTERNET_CONNECTION à True).
Info /Remarque /Rappel: une entreprise dépend d'une localité.
A 1 client (un custom id pour un client) correspond 1 entreprise existante
A 1 entreprise (un custom id pour une entreprise) correspond 1 localité

On devrait avoir un dossier dédier aux seules opérations 'CRUD', et un autre pour les vues sur les modèles métier.

Mettre à jour le schéma (attribut en double, et pour certains modèles il manque des attributs).

L'application log en ligne (betterstack içi).
De plus il y a usage d'API ouverte du gouvernement Français.

Il faut implémenter un mécanisme qui permette de poursuivre l'usage de l'application même en l'absence de connexion internet.
Donc même si l'admin indique en settings qu'il y a accès à internet, il faut prévoir le cas d'un défaut de connexion, et que l'application puisse continué à être utilisée. Noter que la création de nouvelles localités fait appel à une API externe. Une amélioration est attendue afin de simplifier la création d'entreprises (interroger une API avec SIREN+NIC, et rappatrier les informations nécessaires).

La suppression est autorisée, mais on doit favoriser une stratégie d'archivage.
Ennsuite, en cas de suppression il faut s'assurer qu'on respecte le RGPD et qu'on puisse supprimer des collaborateurs, entreprises, sans impacter le fonctionnement de l'application.

Phase initialisation application.
Soit on met tout en anglais. On sera dans le même cas que les messages qu'on log en cas de succès, tous préfixés: Creation ..., Update.., Delete..., .
Soit on laisse en Français mais les messages doivent être intégrés en variables, soit en settings, soit template Jinja.

Traduire le menu help, en anglais.
Prévoir d'ajouter les libellés correspondant dans le template Jinja, puis les servir en Français, si c'est la langue retenue pour l'application.

Initialisation application - Permettre saisie du login admin en argument.
Au lieu de jouer la commande oc12_init_application puis saisir son login, il faudrait permettre à l'admin de le saisir en l'indiquant directement en argument.

Les restitutions sous forme de 'table' (package rich) sont trop extensives, il faut permettre de filtrer en nomre, indépendemment /en plus, des 'filtres par arguments'.

Les contrats font l'objet de règlements pour la totalité du montant dû ou une partie.
On doit gérer les débits /crédits, avoir une balance comptable.

Il faut permettre un débranchement vers un autre SQGB (de type 'relationnel': mysql, sqlite etc) sans atteindre au fonctionnement de l'application.

Prévoir de pouvoir loger en local les évènements de l'appli.

Certaines commandes ont dues être forcées en jouant directement des commandes systèmes. En l'ocurrence 'linux'. Il faut parvenir à tout jouer avec SQLACLHEMY ou prévoir des cas d'usages de remplacements.

Propose graph illustrations and exports.

Afin de durcir la gestion des droits, on devrait implémenter une gestion spécifique pour certaines actions considérées comme critiques. Il faudrait que l'utilisateur fournisse son mot de passe pour valider certaines actions.

Enfin en admettant que son token soit capturé, on peut au moins protéger certaines ressources (voir toutes si on demande un mot de passe pour chaque opération hors consultation).

Adapter les settings et tout message. Uniformiser en une seule langue.