The user package and tests have become somewhat outdated since the new specifications have been set. That's why they need a general clean-up.

The UserController has become a place where all general site functionality has been put into. It would be better if those methods were in their own class in another package.
These methods are:

• impressum()
• home()

Putting them into their own class would also prevent this from happening in the future.

For the ranking system that has to be implemented we need to decide on an algorithm.

Some possibilities from the top of my head are:

• Glicko2
• Elo

Currently this function gets the id of the currently logged in User, checks if a user with this id exists and if not creates one. This is slower than just returning the id of the logged in user.

• Allow page to load ranking data
• Implement pagination
• Allow user to search a user in the searchbar and load the user and the users after him in the rankinglist
• Show position of the logged-in user

The focus has shifted from tournaments to a ranking system. As part of the restructuring that comes with this we need to remove code that's not related/necessary for this.
We need to do the following:

• Clone master to a different branch
• Remove tournaments and teams from working branches that are still to be merged

First feedback on the new frontend showed different things to improve/change:

• Orange color seems distracting and unfitting (change to black)
• Less animation (more sutle animation if use of animation)
• Change 'hitbox' of custom radiobuttons

The front end is supposed to look similar to the profiler and we need mock-ups to agree on a design.

We need some labels to seperate our tasks, please leave some suggestions below

I'm currently working with the new frontend, so for that I want to remove the old or unnecessary stuff.
So here are the thing I want to remove. If you have anything to add oder that you think we should keep, please raise your voice.

So I would suggest removing the following:

• The old header and everything related (CSS)
• The impressum
• The old home page (we dont need it anymore) and everything related (JS and CSS)
• 'simple_user_searchbar.html' (I did this and it isn't usable anymore)
• Everything related to the matches except add as base for the 'match result form'
• Everything related to login and registration as we use KeyCloak

I also would like discussing the following pages as I dont know which is really needed:

• Football Icon (we use Fontawesome, so do we really need them, we don't use them anywhere)
• There is a '_cookieWarning.js' and a 'cookieWarn.js' and there are in use BOTH. They only differ by one line of code, doesn't look like thats intended, we should only keep one)
• Error pages 400 and 404 (they seem usable to me, but I'm not shure if you think so too)
• Index.html (is outdated, we can make a new one if it is required)

Seeking for your Feedback!

After deciding on using ELO for the ranking system we now need to implement it into our application.
Rankings should be separate from our existing packages.
We also need to decide on how to handle the k-factor. Whether it should change with rating and how high it should be set.
We also need to decide on the initial rating a user should have.

The way it is right now only logged in users can access the site. Some pages, like the to be done ranking page, should be able to be viewed by anyone.

There is currently no test case for this.

The method has an empty catch block which catches any Exception.
I would suggest to either fix that or remove it completely as it's of questionable use at the moment.

UserController and MatchController get Basepaths, so we don't have redundancy using /users several times

This function is currently only used in tests and can thus be removed.

Everything is ordered properly that way

There are a lot of useless JavaDoc comments which should be removed.

This is needed for checks in MatchService

UserServiceTest should have the typical given->when->then comment structure

To reduce the chance of abusing the ranking system we need to have players verify the outcome of matches. Besides the notifications on the site we have to send one by mail.

I'm currently reading 'Java By Comparison' and I noticed how hard it can be to understand code, that has really long variable/class names. I think our situation isn't as bad as it was with 'SingleEliminationTournament' or 'MatchResultVerificationRequestRepository'. But still the name 'MatchVerificationRequest' bothers me. Specially when you have the connecting parts like 'MatchVerificificationRequestRepository', I think its really hard to understand what 'MatchVerificationRequest' stands for. The class is supposed to allow the users to verify if a team has won a match, lets take a look which words of 'MatchVerificationRequest' conway meaning:

Match -> The class is about a match, but how is the match relating to this class?
Verification -> The class is about verification, but this is not what it does this class 'verifies' a match
Request -> Is request necessary? Does it add any meaning? I don' think so.

So I personally would suggest changing the name to 'verifyMatch' as it is less confussing, and directly says what the class is suppossed to do to verify a match.

This suggestion might be a bit late, but reading this book, makes me really think about how hard it would be to read our code. I kindly look forward to your opinion and if you have other names that we should disuss to change

Take the user logged-in user and do the following on these sites:

header.html

• Display the user name
• Enable the user to logout with the logout button

profile.html

• Display the user name
• Display the statistics of the user

matchresult.html

• Display and set the user as a default value for the first player of the first team

Please change 'MatchVerificiationRequest' and 'Message' to lower case
like 'matchverificationrequest' and 'message' for naming consistency ;)

The master fails to build because LoginServiceTest is still in the test folders and because anyLong() is used to mock the UserRepository when fetching a user in UserService test. Instead anyString() should be use as the id is a string.

The way matches need to be handled now is completely different from before and the whole component has to be reworked.

Currently it sets the verified attribute but never saves it.

Replace date datatypes with LocalDateTime in Match

profile.html

• Allow user to search and load the profile page of a searched user

Tom suggested us to move UserAlreadyExistsException to the exception package of the user.
Also he suggested us to remove the serialVersionUID from every exception because we don't really now what it does.

As part of the restructuring the idea came up to rework the current database model. We need to layout how the new tables need to look and how the relationships look.

• remove time in match
• upload on github

header

• Load notifications of the logged-in user in the dropdown
• Accepting notification (AJAX request)
• Deleting notification (AJAX request)
• Display the count of unseen notifications
• (Continiously update received notifications while on the site like a messaging service if possible)

Currenty it's possible to search for non existing users. We need to handle it with UserNotFoundException. Catch it in the UserController and return a 404 status.

Currently if you chain methods the spotless only put methods into a new line if it would be over the line limit.
For example:

mockMvc.perform(post("/matches/add").param("date", LocalDate.now().toString()).param("teamAPlayer1", "user")
                .param("teamBPlayer1", "user2")).andDo(print()).andExpect(model().attributeExists("noWinner"));

And I believe it would be more readable like this:

mockMvc.perform(post("/matches/add").param("date", LocalDate.now().toString())
.param("teamAPlayer1", "user")
.param("teamBPlayer1", "user2"))
.andDo(print())
.andExpect(model().attributeExists("noWinner"));

Create and send form to create a new match

We need a new repository method that returns a verifyMatchRequest and needs parameters such as a match but also users. We also need to add another method in verifiyMatchService.

Relates to #41 as we need it for email communication

This would allow us to easier translate the program to different languages and makes it easier to adjust/change text.

Pages we need to create:

• Header
• Ranking
• Profile
• Matchresult

The goal of this issue is to create pages seperate to the backend. In the next sprint we would be able to plug in all functions from the backend.

• Notifcation

• NotificationType (enum)

• NotificationService

• NotificationRepository

• NotificationController

• MatchVerificationRequest

• MatchVerificationRequestRepository

• VerifyMatchService

• Message

• MessageType

• MessageRepository

• SendMssageService

• NotificationNotExistingException

• WrongReceiverException

• MessageDummy

• MatchVerificationRequestDummy

• NotificationServiceTest

• SendMessageServiceTest

• VerifyMatchService

This allows people to build the project without having to install maven themselves.
This is a small change that can be with one command, see: https://github.com/takari/maven-wrapper

UserNotFound and UserDoesNotExist is identical.

As soon as the event API is available we need to implement it in email, match and notification.

• email
• match
• notification

Relates to #37

Implement an event API to allow Services to communicate with each other

• MatchCreatedEvent
  • send requests
• MatchDeclinedEvent
  • delete match
• MatchVerifiedEvent
  • verify match
  • execute ranking

Unnecessary stuff we need to delete:

• Impressum Controller

Stuff we may not need (match package in ressources):

• add.html
• matches.html
• page.html

Currently the user package is hardly tested. Only about half of UserService and UserController isn't tested at all.

These things are wrong in my opinion:

1. Variable is named just 'o'
2. The equals method doesnt follow the proper conformation
   (1. NULL-Check, 2. CLASS-Check, 3. EQUALS-Check)
   -> Comparing 'o' with == seems confusing to me
3. The compare part is kinda long, maybe use the hash instead?

They check whether if the attribute is set or not which can cause NullPointerException's or requires checks elsewhere.