WIP: adding basic sites and ji handling #2
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "arthur.wambst/tests"
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?
Review generale de choses sur plusieurs fichiers:
Les reponses des endpoints, vaut mieux passer l'objet dans le return type de la methode.
Au lieu de:
faire plutot:
Pour le swagger c'est mieux, comme ca il connait l'objet de sortie et ca change pas grand chose, ca fait meme moins de code a ecrire souvent.
Pour certains type de retour, on va faire un objet specifique au lieu d'utiliser le meme que celui de la db. Pour par exemple eviter d'envoyer le mdp hashe dans notre reponse et de pouvoir plus specifiquement decider ce qu'on renvoit sans changer notre objet de db.
Pour plus tard, mais on va faire une methode speciale pour les retour d'erreur histoire que ca soit gere plus bas (genre les repo/services).
En general, attention a bien tester les cas ou le user peut rentrer n'importe quoi
Y'a des trucs qui me derangent dans le fichier
InstanceEndpoint.java
mais c'est plus un truc perso donc pour l'instant je vais laisser ca comme ca.import ununsed dans pas mal de fichiers
Globalement, tous les noms d'endpoints sont au pluriel pour une meilleure coherence. On get les objets avec des id plutot que leur nom.
@ -0,0 +1,72 @@
/**package fr.la_banquise.backend.data.model;
Il est commente, il aurait une importance plus tard ou on peut le supprimer ?
Il sert pour le moment a m éviter d aller rechercher les fonctions de docker java api directement dans le repo vu que y a 0 doc, j l enleverai pour la version finale
@ -0,0 +44,4 @@
this.jiInSite = new ArrayList<Ji>();
}
@Override
l'annotation
@ToString
fait ca pour toidone
@ -26,4 +23,4 @@
@GET
@Path("dashboard")
public Response getDashboard() {
Il manque un
@Authenticated
pour que ca marchedone
@ -27,4 +24,4 @@
@GET
@Path("dashboard")
public Response getDashboard() {
String username = identity.getPrincipal().getName();
unused si ligne 31 commentee
Edit: pourquoi la ligne 31 est commentee du coup ?
j crois que instance.getAllInstace marchait pas ? j re regarderai ca une autre fois
@ -0,0 +43,4 @@
public Response createJi(@QueryParam("name") String name,
@QueryParam("desc") String desc, // TODO : change
// desc to date
@QueryParam("address") String address,
address, description et name_site sont pas deja dans site? Autant utiliser l'id du site du coup. Pareil pour le respo utiliser un id plutot qu'une string
fait en partie, j changerai les string vers id une autre fois
@ -0,0 +59,4 @@
@GET
@Path("/getbyname")
@Produces(MediaType.APPLICATION_JSON)
public Response getJiByName(@QueryParam("name") String name) {
Priviliegier les get by id plutot que by name en regle generale, le front utilisera l'id qui est plus simple pour la db a trouver
ok, j changerai + tard
@ -0,0 +72,4 @@
@DELETE
@Path("/del")
@RolesAllowed("root")
ROOT plutot que root du coup ?
done
@ -0,0 +80,4 @@
"Internal server error, usually site not found")
})
public Response
deleteJiByName(@QueryParam("name") String name) {
par id plutot que par name
@ -0,0 +90,4 @@
.build();
}
}
/*
on peut supprimer tout ca non ?
yep, c etait des restes des anciennes versions de l intra, tp c est devenu ji je crois donc il reste 2 3 trucs, mais la ca m a lair useless, j le del
@ -0,0 +20,4 @@
/**
* TpEndpoints
*/
@Path("/api/subject")
Si possibilites d'avoir plusieurs sujets (i.e. la liste de tous les sujets dispo), mettre subject au pluriel
done
@ -0,0 +52,4 @@
@Path("/respo")
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("ROOT")
public Response addRespoSujet(@QueryParam("name_sujet") String name_sujet,
Camel Case pour les noms de variables ^[a-z][a-zA-Z0-9]*$ (aussi pour les query params)
done en partie, j repasserai dessus une autre fois
@ -0,0 +70,4 @@
@DELETE
@Path("/respo")
@Produces(MediaType.APPLICATION_JSON)
Quand une des annotation est repetitive
@Produces(MediaType.APPLICATION_JSON)
par exemple tu peux le mettre au dessus de ta declaration de class et elle sera pour toutes les method a l'interieur de ta classeeuu jsp si elle est vraiment necessaire en fait, j vois pas clairement c qu elle change
@ -0,0 +71,4 @@
@DELETE
@Path("/respo")
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("root")
des fois
ROOT
des foisroot
pour le rolej ai fait en sorte que ca cree un user avec le role ROOT a chaque boot sur le profil dev, mais root marchait pas j crois
j ai pas encore change partout mais j y fais petit a petit
@ -0,0 +72,4 @@
@Path("/respo")
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("root")
public Response rmRespoSujet(@QueryParam("name_sujet") String name_sujet,
Camel Case pour les noms de variables ^[a-z][a-zA-Z0-9]*$ (aussi pour les query params)
@ -20,3 +29,3 @@
* UserEndpoints
*/
@Path("/api/users")
@Path("/api/user")
Pourquoi il y a deux endpoints differents pour les users ? (et pourquoi celui la il est au singulier?
y avait bcp d endpoints deja pour la gestion des users 1 par 1 donc j ai mis les fonctions qui font des operations sur plusieurs users et j ai mis tout ca dans users, mais jsp si c est mieux que d avoir un seul giga fichier
@ -54,0 +73,4 @@
@QueryParam("role") String role) {
try {
User user = userService.getUser(userId);
user.role.add(userService.fromString(role));
Pas de logique dans la partie rest, ca devrait etre dans une methode dans le service (avec une annotation transaction sinon ca ne marche pas).
un truc du style:
@ -54,0 +89,4 @@
@QueryParam("role") String role) {
try {
User user = userService.getUser(userId);
user.role.remove(userService.fromString(role));
pareil qu'au dessus
@ -0,0 +43,4 @@
}
@POST
@RolesAllowed("ROOT") // TODO: respos JI doivent aussi pouvoir faire ca
@RolesAllowed({ "ROOT", "JI" })
nan ca doit etre que les respo de la JI en question donc flm pour le moment
@ -0,0 +64,4 @@
if (response.success_names.size() == users.usernames.size())
return Response.ok().build();
Map<String, String> retour = new HashMap<String, String>();
pas de logique ici, que dans la couche des services
@ -0,0 +7,4 @@
@RegisterForReflection
public class BulkUserDelResponse {
public List<String> success_names;
Camel Case pour les noms de variables
^[a-z][a-zA-Z0-9]*$
@ -0,0 +7,4 @@
@RegisterForReflection
public class BulkUserPostResponse {
public List<String> success_names;
Camel Case pour les noms de variables
^[a-z][a-zA-Z0-9]*$
@ -0,0 +1,179 @@
/*package fr.la_banquise.backend.services;
Besoin de ca ou pas si il est commente ?
@ -55,3 +70,1 @@
Instance instance = new Instance(name, ssh, pwd, port, user, tp);
instanceRepository.persist(instance);
return instance;
public String createContainer(Long instanceId) {
pourquoi ce qui est lie au container est pas dans le container service ?
@ -0,0 +23,4 @@
@Transactional
public Ji createJi(String name, String description, String address,
String site_name) {
Camel Case pour les noms de variables
^[a-z][a-zA-Z0-9]*$
@ -0,0 +61,4 @@
}
@Transactional
public Instance createInstance(Long id, String username) {
Pourquoi c'est la tout ce qui ne parle pas de ji directement ? Et pas directement dans les services respectifs ? (instance, containers etc...)
@ -0,0 +24,4 @@
@Inject UserRepository userRepository;
@Inject InstanceRepository instanceRepository;
On utilise generalement les services des autres fonctionnalite plutot que leur repo, pour avoir une layer d'abstraction en moins. Par exemple, le SujetService peut acceder au SujetRepository mais devrait acceder aux methode du UserRepository a travers les methode de UserService
@ -0,0 +33,4 @@
return user.sujetRespo;
}
/*public PracticalResponse getTp(Long id, String username) {
Le code commentee a une utilite ou peut etre supprime ?
faut faire les get pour en get qu un seul ou tous ceux dont l user est participant, et j pensais repartir de ca pour aps avoir a rechercher les commandes pour l user
@ -0,0 +68,4 @@
}
@Transactional
public boolean addRespo(String name_sujet, String name_user) {
Camel Case pour les noms de variables
^[a-z][a-zA-Z0-9]*$
done
@ -0,0 +70,4 @@
@Transactional
public boolean addRespo(String name_sujet, String name_user) {
User user = userRepository.find("name", name_user).firstResult();
Sujet sujet = sujetRepository.find("name", name_sujet).firstResult();
une method
findByName
peut etre implem dans les repositoryEdit: Plutot que de faire une recherche sur les noms, autant utiliser l'id de la personne et du sujet. Dans le front on peut faire un auto fill du nom et c'est l'id qui est renvoye, moins couteux pour la creation et plus aligne avec une API
@ -0,0 +71,4 @@
public boolean addRespo(String name_sujet, String name_user) {
User user = userRepository.find("name", name_user).firstResult();
Sujet sujet = sujetRepository.find("name", name_sujet).firstResult();
if (!sujet.respos.contains(user)) {
Que se passe-t-il si le sujet/user n'existe pas ? Toujours controler l'input de l'utilisateur
ca met une erreur degeue de la db, mais pour le moment j me suis absolument pas interesse a la gestion des erreurs
@ -0,0 +79,4 @@
}
@Transactional
public boolean rmRespo(String name_sujet, String name_user) {
Camel Case pour les noms de variables
^[a-z][a-zA-Z0-9]*$
done
@ -0,0 +82,4 @@
public boolean rmRespo(String name_sujet, String name_user) {
User user = userRepository.find("name", name_user).firstResult();
Sujet sujet = sujetRepository.find("name", name_sujet).firstResult();
if (sujet.respos.contains(user)) {
Meme problemes qu'au dessus
@ -0,0 +89,4 @@
return false;
}
/*
* TODO: Seuls les respos du sujet et root doivent pouvoir avoir acces
Je sais que c'est commente mais c'est fait au niveau des endpoints les checks d'acces
aa okeee j changerai ca dans tout plus tard
@ -48,3 +46,3 @@
}
@Transactional
@Transactional // wtf ? this is get user no ?
oui, c'etait histoire d'avoir la methode qq part mais ca avait pas ete implem x)
x))) a changer alors
Checkout
From your project repository, check out a new branch and test the changes.