IV1201-RecruitmentApp

This is the recruitment application for the IV1201 course.

Tools

• Version control (Git)
• Project management (Maven)
• Cloud runtime (Heroku)

Frameworks

• Spring Boot 2.6.3
• Spring Web MVC
• Spring Security
• Spring Data (JPA)
• Thymeleaf
• PostgreSQL
• Bootstrap 5.1.3
• OpenJDK 17

Help

Environment variables

The following environment variables must be set to establish communication with the database.

• JDBC_DATABASE_URL
• JDBC_DATABASE_USERNAME
• JDBC_DATABASE_PASSWORD

General development pattern

resources

• View

java

• Controller
• Model
• Service
• Repository

Resource Bundle

• Localization

Further development

Authorization

To ensure that a user cannot access pages that it is not authorized to access; make sure the URI used to access any restricted page starts with the directory named after its role (i.e. "/applicant/...")

Reset password email

To enable sending the reset password mail to a user, the mail settings need to be configured in application.properties and the line mailSender.send(message) needs to be uncommented in the EmailService.java.

To customize the subject and message sent; change resetpassword.email.subject and resetpassword.email.messagebody in the messages.properties file for each language.

Localization

To add a new localization for use in the UI a messages.properties file needs be added. The configuration file should follow the format messages_XX.properties where XX is the two letter ISO 639-1 code. Additionally to allow easy switching between languages an entry in the language dropdown menu for the added localization should be added to the header.html Thymeleaf fragment.

When adding new messages to the messages.properties, file validation error messages should be added in the top segment and Thymeleaf text elements should be added in the bottom segment.

Also be aware that the application expects the messages.properties files to be ISO-8859-1 encoded. Editing the files using GitHub's web interface (for example when resolving merge conflicts) will currently change the encoding of the file without warning. For this reason ONLY edit these files in your IDE.

Error handling

Errors can be handled in three ways. The first is to handle it in the calling method as normal. The second is to declare a error handling method in the controller class where the instruction started. This is done by using the ExceptionHandler tag on that method. For the last version add ExceptionHandler methods to the GlobalExceptionHandler controller class. Here all exceptions are processed that can't or shouldn't be handled in any other place.

Logging

Logging is done using the standard logger in spring boot. All logging messages are printed to standard out and all stack traces are printed to standard err. To get the log messages to print to a file the logging.file or logging.path needs to be declared in application.properties. Log groups can be defined on application.properties to set different logging behavior for deifferent groups.

Custom security handlers

Custom handlers has been implemented for succesful logout and for authentication failure so that some logging and error handling can be done. If other functionallity is needed for those events the relevant handler needs to be expanded or replaced if the current functionality is no longer needed.

Application status changes

Due to the lack of a 'status' table in the database some functionality is hard coded. Therefore when modifying the statuses of the application one must make sure the methods setStatusOptions in the ApplicationController and makeStatusFromString in the ApplicationService are modified accordingly.

Removing a status is easily achieved by removing the corresponding messageSource.getMessage(message) lines in both methods as well as the corresponding entries in the message_properties file (and all other localization of the file).

Adding a status is achieved by doing the opposite, that is; adding the corresponding status lines in the message_properties file and making references to said file using the messageSource.getMessage(message) method in both setStatusOptions and makeStatusFromString.

Alternatively adding the 'status' table where all statuses are held to the database would allow for simple access through repository calls.

Application search options

The search options presented when searching for applications are hard coded as different search options may require different validation checks, the addition of a table in the database would not solve the issue entirely.

The applications.html view renders only the input elements relevant to the selected search option to solve the issue of parsing what search option to use for subsequent database accesses.

If a 'name' search option is to be added; this input field must be added to the view (where it is hidden depending on the currently selected search option). This field must be added to the ApplicationsListRequestDto as searchName to be passed by the ApplicationListController to the ApplicationListService. The search option is then added to the service which does the corresponding parsing and repository calls as determined by the requests searchType field. The removal of a search option is thus done in the exact opposite manner.