Leo/Backend #82
Labels
No Label
Bug
Done
Pas urgent
Proposition
Question
TODO
Tests
URGENT BORDEL DE Q
Waiting for review
back
front
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PGL/Clyde#82
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Leo/Backend"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce merge enverra dans main : le timeout des token, la limite de 5 token par user, les nouvelles tables pour les demandes d'inscriptions
Quelques petit changement et les test à déplacer sinon ça me semble bon
@ -55,0 +63,4 @@
}else{
tokenService.saveToken(new Token(user,user.getPassword(), new Date()));
}
Junit est installé normalement, ça serait mieux de faire ce genre de chose dans les test !
(Et en plus ça peut rester vu que on sera noté dessu)
J'ai essayé et j'avoues galérer un peu a setup les tests unitaires sur la DB, je vais m'y mettre demain a tête reposée en attendant je nettoies les tests et je les referai propres !
en vrai au pire c'est pas grave mais je ne pense pas que ça ai sa place dans le projet final, genre il faut juste pas le commit et le garder ailleur quoi ^^
entiérement d'accord j'aurai du le nettoyer
@ -58,0 +77,4 @@
c.add(Calendar.DAY_OF_YEAR, 1);
tokenService.saveToken(t);
}
}
same https://git.herisson.ovh/PGL/Clyde/pulls/82/files#issuecomment-1436
@ -37,0 +48,4 @@
public void autoDeleteToken() {
for (Token t: tokenRepo.findAll()){
Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
Calendar.getInstance retourne déjà l'instant ou il est crée
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Calendar.html
C'est bien vu ca
@ -37,0 +52,4 @@
Calendar cal2 = Calendar.getInstance();
cal2.setTime(t.getExpirationDate());
if (cal.get(Calendar.YEAR) == cal2.get(Calendar.YEAR) && cal.get(Calendar.DAY_OF_YEAR) == cal2.get(Calendar.DAY_OF_YEAR)){
peut être faire des >= au lieu des == pour éviter que le programme ne passe au dessus si imaginons le serveur est fermé pendant 2 jours
Mais encore mieux tu pourrais comparer les deux
Calendar
avec la fonction ´.compareTo(Calendar)`https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Calendar.html#compareTo(java.util.Calendar) et juste voir si le résultat est négatif
Excellente remarque ! Ca sera changé dans mon prochain commit !
@ -15,2 +19,3 @@
private Date expirationDate;
public Token(User user, String token){
public Token(User user, String token, Date expirationDate){
ça serrait cool de donner une valeur par défault, comme ça on ne doit pas toujours l'envoyer quand on se connecte
c'est le frontend qui doit nous la donner cette valeur par défaut. (en fct de si leuser veux rester connecté ou non
)
Cringe... but ok
Leo/Backendto WIP: Leo/BackendWIP: Leo/Backendto Leo/Backend@ -0,0 +4,4 @@
import java.util.Date;
public class InscriptionRequest {
il manque pas le pdf du CESS dedans ?
(je dirais que dans un premier temps sans l'upload on peut très bien commit ainsi ? Peut être mettre un todo)
oui tout à fait mais il faut pas oublier le champs d'où le comm
Je penses que c'est dans mon extension donc je l'ai pas mis ! Peut être mb ?
dans le doute mets le nan ?(du moins au moins le todo)
LGTM
du coup j'ai un peu mieux check (oups )
et j'ai juste 2 remarques
@ -44,0 +42,4 @@
public void saveToken(Token token){
//Si l'utilisateur a déja 5 token delete celui qui devait expirer le plus vite
ArrayList<Token> tokenList = tokenRepo.getByUserOrderByExpirationDate(token.getUser());
if (tokenList.size() == 5){
ici aussi faudrait un >=
ban pas vraiment je penses vu que ca s'execute forcément a chaque fois qu'on save un token ! En plus si on permet le >= alors ca casse la limite de 5
Ca permet d'éviter les problème, genre imagine à un moment sans faire attention on va dans la db et on ajoute un token. bha du coup ça crée des tokens à l'infini. si tu met >= au moins t'es tranquil et ça casse pas la limite vu que quand ça passe à 5 ça supprimer quand même
bah alors je peux faire un truc encore plus safe et en delete jusqua ce qu'il en reste 5 comme ca quoi qu'il arrive c'est bon ! De toute manière c'est juste une boucle a ajouter. Ca vous convient ?
yup
@ -0,0 +20,4 @@
//Permet de différencier les demandes de changement et une réinscription dans le même cursus
//Pour la réinscription on va le mettre a 0
private boolean type;
je comprends pas à quoi type sert (dans le sens où : pourquoi on devrai différencier les demande de réinscriptions dans le même cursus ou non ?)
et le nom " type" est fort abstrait
parceque que j'aimerai bien pouvoir séparer les deux dans l'interface par la suite mais que leurs données sont similaires donc j'ai utilisé ca pour les différencier dans la même table ! Je suis d'accord que le nom est fort abstrait on pourrait envisager un truc comme isCursusChange.
par pitié fais de l'héritage alors en séparant cursus change et réorientation
mais le but c'est justement de pas avoir deux tables pour deux données qui ont les mêmes attributs
https://www.baeldung.com/hibernate-inheritance
New commits pushed, approval review dismissed automatically according to repository settings
New commits pushed, approval review dismissed automatically according to repository settings
C'est bo
Je suis sur téléphone et c'est chiant à mourir deval la dessus alors je trust