Service aggregating events¶

Brief description of the system¶

The goal is to create a website that will allow the organizers to enter events and collect entries. Every registered user can sign up. The website should also be equipped with an event search engine (with several criteria) and an API that will enable the presentation of these events on other sites/services.

Main system functions¶

• User registration and login.
• Events created and edited by organizers (user with special role).
• Commenting on events by userswho are logged in.
• Signing up for events.
• Event search engine.
• API for other websites/services willing to present events.

General guidelines¶

Building a website using Spring, JPA (Hibernate) and Thymeleaf as the view layer (or Angular / React). Introducing the division in the application into DAO, services, controllers (REST controllers in the case of using Angular or React) and placing the appropriate logic into each of them. Securing access to applications and functionalities using Spring Security.

Functionalities¶

Home¶

• creation of the first controller and view file
• creating files with style / script definitions (bootstrap or custom) that will be attached to each subsequent page (use include, block if you are using Thymeleaf)
• in the upper section of the page there should be the name of the website and the log in and register buttons

User registration¶

• The registration form should contain:
  • a login window (email) – checking for correctness of the e-mail,
  • a password window – must be at least 8 characters long, but no more than 30 (the user should confirm the entered password)
  • a name to display - the field cannot be empty or contain all white characters, and the maximum length is 50 characters.
  • a user with a given email can register only once.
• the user should be associated with the roles in the system, which will include at least two cases: an organizer and an ordinary user. Each registered person is always assigned the role of "regular user".
• the password is kept in the database in the form which prevents it from being displayed/recovered.

User login¶

• login form containing a login and a password checkboxes.
• logging in using Spring Security (to create the appropriate configuration).
• after the user has successfully logged in , he/she should be redirected to the home page. Here instead of the login/register buttons, information such as: "Logged in as: email" will be displayed.

Adding a new event¶

• the event must contain at least:
  • a title - the field cannot be empty or contain only white characters,
  • dates from/to - mandatory (optional checking if the date is a future date),
  • a description - a minimum of 20 characters.
  • the event must be associated with the user who adds it.

List of events¶

• In the central part of the webpage, a list of all current events should be placed
• Each element of the list should contain:
  • a highlighted header with the title of the event,
  • dates from/to the event,
  • the first 50 characters of the description.
  • events should be sorted in chronological order.

Event search engine¶

• Add a form containing at the top of the home page:
  • a text field for entering the phrase,
  • an optional dropdown field: future, ongoing and future, all
  • the "search" button.
  • the entered phrase can be searched in the title.
  • search results are to be placed on a separate page, in the same layout as on the home page.
  • the search results page should also have a search form same as on the home page. Its fields should be set according to the currently selected criteria.

Detailed view of the event¶

• A separate page with all event features should be created: title, dates from/to, full description.
• The title should be linked on the home and on the search results page. When clicked, it is transferred to the page of a specific event.

Adding comments to the event¶

• A form for adding a comment should be placed under the general information about the event.
• A comment can be up to 500 characters long.
• Only logged in users can add a comment.
• The code with the form should display all comments added so far, in descending order.

Signing up for an event¶

• On the event page, an option (button) to sign up must be added, but only for logged in users.
• If the current user is already signed in, he sees the relevant information instead of the button. Optionally, a button to unsubscribe from the eventcan be added.
• A list of all currently registered users should be placed next to general information about the event.

API for other services - event listing¶

• The API should follow REST rules
• The user should be able to download a list of all future events.
• Optionally, the user can additionally filter the events based on a date range.

Application displaying events downloaded from API¶

• Build a second application (using Spring + Thymeleaf/Angular/React), which will consume the event API and display the list in a view
• Optional: add the option to filter events in the application for the selected date range, using filtering on the API side

Additional tasks and extensions¶

Ability to add a picture to the event¶

• Add the ability to upload an image to the event adding / editing form.
• Save the uploaded file on a disk or in some external cloud storage service via API or make such a service yourself with your own API (advanced versions)
• Uplaod the file for the purpose of displaying it in the event details pane (or in other places).

Editing an event¶

• An additional page that will allow you to edit the created event.
• Only the owner or administrator of the website can edit the event (new role for the user).
• The edit option should appear at least on the order details page.

My Events¶

• A section for the logged in user, where he will see all the events, both those in which he participated and those owned by him.
• The latter should be able to switch to editing (mechanism in the previous task).

• The list should allow filtering by:

  • role:

    • all
    • organizer
    • participant

  • when:

    • future
    • ongoing and future
    • past
    • all

    • date (opctional):

      • field from
      • field to

Additional requirements¶

• It is necessary to ensure an aesthetic and functional way of presenting data
• Data downloaded from users should be pre-validated