• During registering when we check 'Je souhaite faire un compte vendeur' we need to set the focus automatically to the RIB input.
• When we register and succeed we need to skip login and be redirected to home page.
• When trying to validate or clear an empty cart we get a success message.
• As an admin, available nor accessible the option "Devenir vendeur" should be not.
• The possibility to add to cart then buy nothing but our veriest own pictures while impersonating a seller might be not given.
• The date of an individual's purchase on display in the "Mes commandes" entry could be intelligible.
• We may suggest that an input has been wrongly submitted by displaying an error message of some kind if any user type an incorrect password or login in order to sign in.
• Selling a picture with a negative price is a feature which may be seen as debatable from an economical standpoint.
• When the price of a picture is fixed above a determined threshold, we could give a feedback saying that the picture is a bit overpriced.
• Since our website is focused on the sale of digital pictures, letting the possibility of buying a picture twice, despite its commercial interest, could be perceived as a slightly morally questionable practice.
• When a duplicate member is created, the wildfly server shouldn't crying errors until its mere body become dry.
• An empty cart shouldn't be possibly validated.
• Similarly, an already empty cart shouldn't be possibly emptied.
• When someone mess a little with the search engine, it sometimes says the expected number of matching pictures has been found, but return every picture in the database instead. It doesn't seem to be an elasticsearch related issue, since the json and http requests and all that stuff seem fine to me after a bit of investigation, so I suspect that's something which has more to do with the frontend and the way these things are handled instead. Unfortunately, I haven't succeeded in finding the exact buggy pattern after a while on it, but it shows itself quite often (unless when you try to reproduce it, of course).
• When someone wants to upload several pictures at once, if the last one is added by using the "Valider et Rajouter" button, and only then the transaction is confirmed thanks to the "Valider et Terminer" button without submitting any other picture this way, there isn't any kind of feedback telling the user that the transaction has succeeded, no message or redirection to the picture management page contrarily to the case where the last picture ends the transaction with the "Valider et Terminer" button.
• After adding a picture to an upload transaction with the "Valider et Rajouter" button, the picture, the price and the description fields aren't affected and keep their informations. Nevertheless, one may think that resetting them could be an improvement.
• Not sure that an user needs to know its member ID in the "Mon compte" section, coz it's more a system info than something useful for a lambda member.
• The pictures layout on the home page can be kinda weird, although the thumbnails are resized to have the same width, the site still struggles to put them into rows rather than into columns, which should be way easier, poor one. That leaves quite many areas unfilled if the pictures' formats differ too much and some could consider the result as a bit unaesthetic.
• If we judge keeping in memory pictures for a forecoming purchase a possible use of our feature "add to wishlist", to give the possibility of going on these pictures pages from the "Mes photos favorites" one in one clic, or even better, to add them to cart directly should be a wise improvement.

Pour reproduire le bug:

Connecte-toi --> rafraîchis la page!

La route api/photos/search/ sans tag ensuite donne un beau message d'erreur.

A seller should not follow himself (herself)

The login of the seller will be shown instead of the id (when looking at the people we follow)

This bug was reported by Marwen, I'll fix it

1. créer un membre.
2. se déconnecter.
3. essayez de recréer le même membre (avec le même password)
4. vous voila connecté :p

protect data

In order to do not communicate the location of the photographies, we will need to find a way to mask data when we send it to the client.
For example the photo have a field : "filelocation" this is the path to the real photo (the one we want to sell). We will need to keep it on the server.
An other example is for the user's password. Even if the user know his password we should keep it on the server. (an other issue should be to encrypt those password).

I have to solution possible a the moment :

• Create a table in the data base where we will link the private data.
• Create several DTO kind : publicPhotoDto, privatePhotoDTO etc (I am not sure of this version) .

When the Signal table is created in the database, it's not creating it with the two pks: member pk and photo pk. The only pk is memberid.

It's maybe related to the fact that there is no: private Collection signaledPhotos; (with the respective annotations) in the Member entity. The same would be needed in the Photo entity.

The date of the purchase is not stored in the database (table orders) and therefore it's not stored in the "mes commandes" part of the website.

dans accueil.html, c'est mal ...
faire un hotfix dès que possible.

When the user wants to login and the information is not correct (it's not in the database), there is no information returned to the user. The HTTP 500 (Internal Server Error) can be seen in the browser console.

En tant qu'administrateur, si on crée un nouveau membre via l'interface Manage member et que cette création échoue (violation d'une contrainte d'unicité, par exemple), la ligne correspondant à ce membre apparaît tout de même dans le tableau de la page alors que celui-ci n'existe pas.

Dans le code beaucoup de constante ou chaîne de caractère sont utilisées. Par exemple, pour savoir si un utilisateur est connecté il faut récupérer l'attribut "principal" de la session http.
Autre exemple : les access group : "member", "seller". Il serais plus propre d'avoir des constante statiques dans une class afin de transformer "seller" par SecurityStuff.ACCESS_SELLER.

The first time the seller page description is modified, it is well saved in the database. However, this is not the case from the second time.

Il faut rédiger des tests unitaires JUnit pour chaque US développée. De préférence, ceux-là ne doivent pas être rédigés par le développeur. Si on le fait pas au fur à mesure que l'on valide les US, on se retrouverait avec énormément de codes de production et peu de tests.

Viens causer avec moi Marwen. :p

When uploading a pic in IE 11, the pic is not added and the name is stored as the whole path in the computer where it was stored in.

Il faudrais dès que possible crypter les mots de pass dans la bdd.

Comme les orders doivent avoir une référence sur le vendeur également car nous devons lui transferer l'argent.

Actuellement les réponses du serveur sont créer à la volée . Il serais interressant de creer une réponse plus spécifique a notre application.
Par exemple on pourrais avoir un champ :

 alert {
      type : "success",
      message "opération success"
}

Cette alerte serais alors traduite dans l'application comme une alerte général pour l'utilisateur.
Ce n'est qu'un exemple parmis beaucoup je pense.

La partie mapping entty/DTO est mal faites. Car si on veut faire la transformation d'un seller par exemple en DTO. Celui ci possède une collection de photo (et inversement une photo à une reeference sur un seller). Dans notre architecture actuel, cela implique d'avoir une référence sur un autre dao dans un dao.
C'est absolument à évité. Il faudrais peut etre créer des classes de mapping spécifique.
J'ai trouvé une api intéréssante qui pourrais faire l'affaire

We should integrate log4j in order to have applications logs.

Quand on refresh ma page, le nombre de follower ne s'affiche pas correctement

dans la bar de navigation, si on est juste membre l'onglet "ma page" est affiché.

Le code angular est un peu "dirt". Il faudrais le refactorer.
Par exemple trouver le moyen de généraliser les message d'érreurs (comme pour la page d'inscription).