nickdelta / hermes-internal-front-end Goto Github PK

Πρέπει να υλοποιηθεί το view που θα βλέπει ο/η Organization Suervisor όταν θα μπαίνει στο σύστημα.

Ας γίνει μια μικρή τεχνική ανάλυση που φανερώνει και τα ζητούμενα:

Οι supervisors απλά διαχειρίζονται τον κατάλογο χρηστών των υπάλληλων του οργανισμό στο οπόιο εργάζεται. Το Use Case μοιάζει με το User Management κομμάτι του #1 με τη διαφορά ότι ο/η supervisor δεν έχει πρόσβαση σε όλους τους οργανισμούς. Πρέπει να παίρνεις την πληροφορία του σε ποιον οργανισμό έχει δικαίωμα management από το token του και να το προωθείς στο Repository σου για να γίνει το σωστό αίτημα στο Custom Organization REST API μας το όποιο περιγράφεται στο NickDelta/hermes-keycloak-image#4 και επίσης έχεις παράδειγμα χρήσης από το #1.

• Οπότε πρέπει να φτιάξεις ένα OrganizationEmployeesRepository interface και ένα Impl του interface αυτού. Οι μέθοδοι του interface αυτού πρέπει να καλύπτουν το βασικό CRUD. Σχολίασε σε αυτό το issue το interface σου όταν το φτιάξεις για να δω αν είσαι στον σωστό δρόμο.

Πάμε σε πιο Vaadin-specific πράγματα:

• Θα χρησιμοποιήσεις το CRUD Component για να φτιάξεις το view σου. Από εκεί και πέρα θα χρειαστεί:
  - Να κάνεις @Autowired το CrudEditor<UserRepresentation bean για να πάρεις έτοιμη τη φόρμα των χρηστών. Το #1 δίνει περισσότερες λεπτομέρειες για το σκεπτικό πίσω από αυτό.
  - Να δέσεις το Grid του CRUD Component με το UserRepresenation entity του Keycloak (απλά κάνε copy-paste το κατάλληλο μέρος από το PR μου #2)
  - Να φτιάξεις έναν OrganizationEmployeeCrudPresenter που θα δένει το View με το Repository (για Error Handling κυρίως)
  - Στο view να δέσεις τον Presenter με τους διάφορους listeners.

• Το @Route σου θα έχει τη διαδρομή /organizations/employees και αν καταφέρεις να χώσεις και ένα δυναμικό /{organization} ανάλογα με το που εργάζεται το άτομο που έχει πρόσβαση στο view θα είσαι αστέρι.

• Το View θα ονομάζεται OrganizationSupervisorView

• Μην ξεχάσεις να ασφαλίσεις το View σου. Ο ρόλος του/της supervisor είναι ο ROLE_ORG_SUPERVISOR

Αυτή η δουλεία είναι σχετικά εύκολη γιατί έχει αρκετές ομοιότητες με το #1 , οπότε περιμένω να παραδωθεί σχετικά γρήγορα.

Συνοπτικά έγιναν οι ακόλουθες αλλαγές:

• Έγινε ένα bump στις εκδόσεις, συγκεκριμένα:

  • Bump Spring Boot σε 2.3.8
  • Bump Vaadin σε 14.4.7
  • Bump Keycloak σε 12.0.2 (ως συνέπεια του NickDelta/hermes-keycloak-image#6)

• Προστέθηκε το απαραίτητο profile στο pom.xml ώστε να μπορεί να παραχθεί το jar σε Vaadin Production Mode

• Ο τελικός χρήστης πλέον μπορεί να επιλέξει ανάμεσα σε 3 Locale (το δικό του/Ελληνικό/ΗΠΑ). Είναι λίγο χαζό αλλά απλά ήθελα να υλοποιήσω δείγμα μιας τέτοιας λειτουργικότητας

• Το ίδιο ισχύει και για το timezone του καθώς μπορεί ο χρήστης πλέον να κάνει εναλλαγή ανάμεσα σε όποιο timezone του GMT επιθυμεί (πάλι δεν είναι ακριβώς όπως πρέπει αλλά δεν πειράζει)

• Κατασκευάστηκε ένα νέο Vaadin Component TrimmedTextField που είναι υποκλάση του TextField και φροντίζει να κάνει trim() το κείμενο πριν το bindάρει κάπου (χρήσιμο γιατί διάφορες εξαιρέσεις συνέβαιναν με trailing spaces, έτυχε στον @j-christou)

• Από τις πιο σημαντικές αλλαγές : Ενα συνολικό refactor των views. Πλέον μέσω abstract κλάσεων τα views κληρονομούν την περισσότερη από την λειτουργικότητα τους. Αποφεύγουμε boilerplate κώδικα, ο κώδικας γίνεται πιο ευάγνωστος και τα λάθη αποφεύγονται πιο εύκολα.

• Έγινε ένα minify στα media μας ως προς το μέγεθος(εικόνες κτλ). Μερικές εικόνες ήταν υπερβολικά μεγάλες και σε κανονικές συνθήκες θα φαινόταν λίγο unresponsive η σελίδα

• Ανανεώθηκε ο custom Keycloak Client ώστε να υποστηρίζει το νέο Citizens endpoint που ήρθε με το NickDelta/hermes-keycloak-image#6

• Η εφαρμογή έγινε dockerized, φτιάχτηκε ένα μίνι pipeline στο Cloud Build και είμαστε έτοιμοι στο να τροφοδοτήσουμε το prod μηχάνημα μας με εικόνες

Υπήρχαν κάποια misconceptions σχετικά με το πως το Vaadin διαχειρίζεται uncaught exceptions. Πίστευα ότι μέσω του interface HasErrorParameter ίσχυε για όλες τις περιπτώσεις. Τελικά ενεργοποιείται μόνο για exceptions που συμβαίνουν μόνο κατά το navigation. Οπότε exceptions που συμβαίνουν εκτός αυτής της φάσης δεν διαχειρίζονται από κάποιον με αποτέλεσμα το κρασάρισμα του session. Μετά από επικοινωνία με τους devs του Vaadin δεν υπάρχει τρόπος για ωραίο exception handling με έναν decoupled τρόπο (σαν το @ExceptionHandler στο Spring πχ). Οπότε πρέπει να προσαρμοστεί ο κώδικας στα νέα δεδομένα.

Έξτρα μικρότερες αλλαγές:

• Θα αλλάξουν τα ονόματα πολλών κλάσεων για να είναι πιο readable.
• Θα αλλάξει ελάχιστα η δομή των Repositories/Presenters τώρα που υπάρχει πιο ξεκάθαρη εικόνα
• Αυτό το issue θα διορθώσει επίσης οποιοδήποτε μικροbug παρατηρηθεί.

Παρατηρήθηκε ότι όταν πετιούνται εξαιρέσεις, το stack trace τους δεν εκτυπώνεται στην κονσόλα. Αυτό έχει να κάνει μάλλον με τους Error Handlers που έχουν προσφάτως φτιαχτεί. Πρέπει κάποια στιγμή να διορθωθεί αλλιώς δεν θα μπορούμε να κάνουμε εύκολο debugging.

Σκοπός είναι να δημιουργηθεί ένα view που να μπορεί κάποιος να διαχειρίζεται τους πολίτες του συστήματος. Μόνο οι διαχειριστές οργανισμών (ROLE_ORGS_ADMIN) θα μπορεί να έχει πρόσβαση σε αυτό το view.

Κάποιες συνοπτικές τεχνικές λεπτομέρειες:

• Φτιάχνεις ένα νέο interface που θα το λένε CitizenRepository. Βάζεις τις συνηθείς μεθόδους που υπάρχουν και στα άλλα repositories (με όσες αλλαγές χρειαστούν)
• Θα φτιάξεις ένα Impl του CitizenRepository interface με την ονομασία CitizesRepositoryImpl. Για την υλοποίηση των μεθόδων θα χρησιμοποιήσεις το νέο endpoint citizens που έφτιαξα στο keycloak. (TODO: Να θυμηθώ να συνδέσω issues)
• Θα φτιάξεις έναν Presenter CitizenCrudPresenter που θα μοιάζει με τον OrganizationUserPresenter, κάνοντας τις απαραίτητες αλλαγές.
• Έχεις έτοιμο τον CrudEditor σου. Απλά κάνε @Autowired το CrudEditor<UserRepresentation> bean που έχω φτιάξει.
• Για το view θα βασιστείς στο EmployeeView ως πρότυπο. Κάνε τις απαραίτητες αλλαγές για να συμβαδίζει με τη ζητούμενη λειτουργία.
• Το view έχει path /citizens

Πρέπει να υλοποιηθεί το view που θα βλέπει ο/η υπάλληλος οργανισμού όταν θα μπαίνει στο σύστημα.

Ας γίνει μια μικρή τεχνική ανάλυση που φανερώνει και τα ζητούμενα:

• Ο Employee διαχειρίζεται τις αιτήσεις που κάνουν οι πολίτες στον οργανισμό τον οποίο εργάζεται. Οπότε πρέπει να επικοινωνείς με το δικό μας backend. Για να γίνει η επικοινωνία θα πρέπει να χρησιμοποιηθεί το KeycloakRestTemplate. Έτσι το Keycloak θα δημιουργεί μόνο του Bearer Tokens και ο client θα προσθέτει αυτόματα Authentication header σε όποιο αίτημα γίνεται. Στην ουσία Βιβ αυτοματοποιείται η διαδικασία που σου είχα δείξει στο Postman.
  • Μη ξεχνάς ότι το KeycloakRestTemplate είναι extension του γνωστού RestTemplate του Spring. Οπότε ότι docs διαβάσεις σχετικά με αυτό πρέπει να ισχύουν. Χρήσιμα links:
    • https://www.baeldung.com/rest-template
    • https://www.baeldung.com/spring-rest-template-error-handling (Θα χρειαστεί να υλοποιήσεις και error handling αλλά ίσως αυτό είναι δύσκολο για σενα. Κοίταξε το και αν δεν τα καταφέρεις θα βοηθήσω σε αυτό το κομμάτι)
    • https://www.keycloak.org/docs/latest/securing_apps/index.html#client-to-client-support (Έχει ένα minimal example δες εκεί που κάνει autowire το KeycloakRestTemplate)
  • ΠΡΟΣΟΧΗ: Το Base URL του backend πρέπει να είναι ικανό να αλλάζει μέσω μεταβλητής περιβάλλοντος. Θα μιλήσουμε σε σύντομο call για το τι εννοώ.
  • Οπότε πρέπει να φτιάξεις ένα OrganizationApplicationsRepository interface και ένα Impl του interface αυτού. Οι μέθοδοι του interface αυτού πρέπει να καλύπτουν το βασικό CRUD. Σχολίασε σε αυτό το issue το interface σου όταν το φτιάξεις για να δω αν είσαι στον σωστό δρόμο.

Πάμε σε πιο Vaadin-specific πράγματα:

• Θα χρησιμοποιήσεις το CRUD Component για να φτιάξεις το view σου. Από εκεί και πέρα θα χρειαστεί:

  • Να μεταφέρεις τα entities στο front-end. Προσοχή, δεν χρειάζονται τα annotation του Hibernate, κρατάς όμως τα annotation του Hibernate Validator. Δες εδώ ποια είναι αυτά. Σε συμβουλεύω να το κάνεις γιατί μετά μπορείς να χρησιμοποιήσεις το ειδικό Validator του Vaadin που καταλαβαίνει τα Hibernate Validator annotations.
  • Να φτιάξεις έναν CrudEditor για τα applications. Είπαμε ότι μόνο το state θα επιτρέπεται να τροποποιεί ο/η υπάλληλος προς το παρών. Το Component που πρέπει να χρησιμοποιήσεις εδώ είναι το Select. Δες στα παραδείγματα πως να το δέσεις με το Application entity μας.
  • Να δέσεις το Grid του CRUD Component με το Application entity μας. Με άλλα λόγια να φτιάξεις τις στήλες του Grid.
  • Να φτιάξεις έναν OrganizationApplicationCrudPresenter που θα δένει το View με το Repository (για Error Handling κυρίως)
  • Στο view να δέσεις τον Presenter με τους διάφορους listeners.

• Το @Route σου θα έχει τη διαδρομή /organizations/employees και αν καταφέρεις να χώσεις και ένα δυναμικό /{organization} ανάλογα με το που εργάζεται το άτομο που έχει πρόσβαση στο view θα είσαι αστέρι.

• • Το View θα ονομάζεται OrganizationEmployeeView

• Μην ξεχάσεις να ασφαλίσεις το View σου. Ο ρόλος του/της υπαλλήλου είναι ο ROLE_ORG_EMPLOYEE

Προσπάθησα να ήμουν όσο πιο αναλυτικός γίνεται γιατί καταλαβαίνω ότι αυτό το τασκ σου φαίνεται για βουνό. Προφανώς και δεν γίνεται να εξηγήσω κάθε παραμικρή λεπτομέρεια γιατί θα έπρεπε να γράψω έκθεση. Δες το δικό μου PR, δες τι σου γράφω και αν κολλήσεις κάπου θα σε βοηθήσω.

Συνοπτικά,

• Πρέπει να προστεθουν manifests του k8s που να κάνουν deploy το internal-frontend στο GKE Cluster μας.
• Πρέπει να προστεθεί το Spring Boot Actuator για να έχουμε εύκολα και γρήγορα health checks για την εφαρμογή μας. Μέσω των έτοιμων readiness και liveness probes που δίνει, θα μπορεί πανεύκολα το k8s να εντοπίζει πότε το pod είναι έτοιμο να δεχτεί traffic και πότε δεν είναι υγιές. Το άρθρο αυτό εξηγεί πολλά : https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot. Προσοχή, τα endpoints του actuator πρέπει να έιναι εκτεθιμένα στη θύρα 9001 και όχι στην 8080 για να αποφύγουμε την έκθεση τους σε επίπεδο service.
• Πρέπει να προστεθεί ένα βήμα στο CI/CD Pipeline μας, το οποίο θα αυτοματοποιεί το deployment στο GKE. Η Google δίνει έτοιμο τον gke-deploy builder που διευκολύνει πολύ την διαδικασία για εμάς.

Πρέπει να υλοποιηθούν τα Views που θα βλέπει ο/η διαχειριστής/στρια οργανισμών.

Τεχνικά, είναι το μόνο use case που πρέπει να γίνουν 2 views για αυτό:

• 1 view για να μπορεί θα μπορεί ο/η διαχειριστής/στρια οργανισμών να δει όλους τους οργανισμούς που είναι καταχωρημένοι στο keycloak.
• 1 view στο οποίο θα μπορεί ο/η διαχειριστής/στρια οργανισμών να μεταβαίνει για να διαχειρίζεται τους/τις supervisors του οργανισμού που επιλέχθηκε στο παραπάνω view.

Και για τα 2 views θα χρησιμοποιηθεί το CRUD Component ως βάση. Από εκεί και πέρα πρέπει να κατασκευαστούν:

• Ένα CrudEditor<UserRepresentation> που ουσιαστικά είναι η φόρμα για τη δημιουργία/επεξεργασία χρήστη στο CRUD. Μάλιστα θα γίνει και Bean με prototype scope για να μπορεί να επαναχρησιμοποιηθεί σε άλλα views (Ανεξαρτήτως τον ρόλο που έχει ένας χρήστης, τα πεδία του είναι ακριβώς τα ίδια - απλοποίηση που είχα σκεφτεί και πλεονεκτημά μας, δεν είναι ανάγκη να παιδευόμαστε τσάμπα).
• Ένα CrudEditor<GroupRepresentation> που φτιάχνει τη φόρμα για δημιουργία/επεξεργασία των οργανισμών (εύκολο γιατί μόνο όνομα έχει για πεδίο). Δεν θα γίνει bean γιατί δεν χρειάζεται σε παραπάνω από 1 views.
• 2 Repositories που θα επικοινωνούν με το Keycloak μέσω του HermesKeycloak client και θα κάνουν το απαραίτητο CRUD. Χάρις το NickDelta/hermes-keycloak-image#4 αυτό είναι πανεύκολο.
• 2 Presenters που είναι οι γέφυρες μεταξύ των repositories και των views (εφαρμόζουν το error handling κτλ)
• Τα 2 views

Θα ανέβουν screenshots και βίντεο που θα δείχνουν το οπτικό αποτέλεσμα (σε κανονικά πρότζεκτ για γνώση σας υπάρχει ολόκληρο UX team με ειδικά λογισμικά όπως το Adobe XD που κάνουν αυτή τη δουλειά αλλά εδώ είναι πιο παιδικά τα πράγματα, το σταυρό μας να κάνουμε που με ελάχιστη γνώση front-end θα παράξουμε πολύ καλό αποτέλεσμα).