Tests for the isChangeAllowed helper method:

• Verify that the method returns true for valid password change data.
• Verify that the method returns false for invalid password change data.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Tests for the getUserById method:

• - Verify that the method returns the correct user based on a valid ID.
• - Verify that the method throws a UserNotFoundException for a non-existent ID.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Assignees:
Due date:

Create the content of building project instruction

• Instructions for building the project description

Tests for the loadUserByUsername method:

• Verify that the method returns the correct user based on a valid username.
• Verify that the method throws a UsernameNotFoundException for a non-existent username.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Unit test for the findTokensByExpiresAtBefore query:

• Mock the TokenRepository dependency.
• Prepare a list of tokens with different expiration dates, including some that are expired and some that are not.
• Mock the behavior of the token repository to return the prepared list of tokens.
• Invoke the findTokensByExpiresAtBefore method and verify that only the expired tokens are returned.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Unit test for the addRoleToEntity method:

• Verify that it correctly adds the role to the user entity.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Unit test for the isUserAlreadyTeacher method:

• Verify that it returns true when the user has the teacher role.
• Verify that it returns false when the user doesn't have the teacher role.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

fill in your details, linking github data to discord required

• change of branch name
• making sure that any security that was on the Main branch is still on the Develop branch

Assignees:
Due date:

Create the content of a project description.

• A project description specifying what the application is for.

Unit test for the createRefreshToken method:

• Provide a valid username and issuer.
• Verify that the method successfully creates a refresh token.
• Verify that the created refresh token contains the expected claims.
• Verify that the refresh token has an expiration time set correctly.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Tests for the confirmChangeUserPassword method:

• Verify that the method successfully confirms a user's password change based on a valid token.
• Verify that the method throws an exception when the provided token does not exist.
• Verify that the method throws an exception when the provided token is not of the password change confirmation type.
• Verify that the method throws an exception when the token has already been confirmed.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

-Refactor UserRepository scope to package default
-fix outside methods usage to be handled through UserService

The following methods need to be modified:

• whenGetUserById_thenCorrectUserShouldBeReturned
• whenGetUserById_thenUserNotFoundExceptionShouldBeThrown
• whenGetUserByUsername_thenCorrectUserShouldBeReturned
• whenGetUserByUsername_thenUserNotFoundExceptionShouldBeThrown

These methods require changes to adhere to the given-when-then convention using BDDMockito syntax and correct stubbing syntax e.g.:

Method "whenGetUserById_thenCorrectUserShouldBeReturned":

• Change the stubbing syntax from "when(userRepository.findById(ID_1L)).thenReturn(Optional.of(user));" to the equivalent BDDMockito syntax using given().
• Update the stubbing syntax from .thenReturn to .willReturn for consistency.

add scripts directory
add a script to build a postgresql database from docker in 2 versions:

• Linux (sh or bash)
• Windows (cmd or bat)

add information to the README.md file and building the database using a script

Tests for the getUserByUsername method:

• Verify that the method returns the correct user based on a valid username.
• Verify that the method throws a UserNotFoundException for a non-existent username.

instructions for the task:
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Tests for the createUser method:

• Test the successful creation of a new user and verify that it returns the correct data.
• Verify that the method throws an exception when provided with invalid user data (e.g., empty username, password, etc.).
• Verify that the method throws an exception when the provided username is already taken.
• Verify that the method throws an exception when the provided email address is already taken.
• Verify that an email with a registration confirmation link is sent.

instructions for the task:
use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Unit test for the verifyAndReturnDecodedToken method:

• Prepare a valid token and mock the JWTVerifier.
• Verify that the method successfully verifies and decodes the token.
• Verify that the decoded token contains the expected claims.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Tests for the changeUserPassword method:

• Test the successful change of a user's password and verify that an email with a password change confirmation link is sent.
• Verify that the method throws an exception when the provided user does not exist.
• Verify that the method throws an exception when the provided new password data is invalid.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

1. When creating a Pull Request, GH Action should automatically assign the person issuing the PR to the Assignees field.
2. It should also automatically point to the Tutoring platform project

Labels should be set considering the name of the pull request

• bugfix/
• doc/
• feature/
• hotfix/
• refactor/

Unit test for the createAccessToken method:

Provide a valid username and issuer.
Verify that the method successfully creates an access token.
Verify that the created access token contains the expected claims.
Verify that the access token has an expiration time set correctly.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Assignees: dawciobiel,
Due: 03.07.2023

Create contributors list

Tests

N/A

Unit test for the addTeacherRoleToUser method:

• Verify that it correctly adds the teacher role to a user when the user doesn't already have that role.
• Verify that it throws a UserIsAlreadyATeacherException when the user already has the teacher role.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

add .github/workflow/build.yml which will create code from pull requests merged into development

launching the project build:

• during Pull Request from branches feature/ to develop or main
• when pushing code to develop or main
• include in build.yml ignoring changes to .gitignore, LICENSE, README.md, docs files

in order not to waste free resources of github action minutes
build.yml should ignore contributors.md

create a dockerfile in the tutoring-platform/docker folder that will be used to expose spring-boot applications on port 8080

Teacher feature is included in User package atm, it should be handled through User classes, not separated ones.
Any new "user type" should be managed by proper roles.

Description

The @Data annotation, commonly used with Lombok, provides convenience by automatically generating common methods such as equals, hashCode, and toString. However, when applied to JPA entities, this annotation can lead to performance degradation and memory issues. This article discusses the problems associated with using @Data on JPA entities and suggests alternative approaches to mitigate these concerns.

1. Performance Impact:

   The @Data annotation generates equals and hashCode methods that consider all fields of the entity class, including collections and complex relationships. In entities with numerous associations or large fields, the comparison and hashing operations become computationally expensive. This can adversely affect the performance of operations involving duplicate detection, set membership checks, or hash-based data structures like HashSet or HashMap.

2. Memory Usage:

   The generated toString method by @Data includes all fields of the entity, including potentially large values. When working with a large number of entities or performing batch operations, invoking toString can consume excessive memory due to the concatenation of these fields. This can lead to memory-related issues, especially in memory-constrained environments.

For more information, please refer to the following article: Lombok and JPA: What May Go Wrong?

Action:

• Review all JPA entities in the application for the usage of the @Data annotation.
• Replace the @Data annotation with appropriate Lombok annotations like @RequiredArgsConstructor, @Getter and @Setter.
• Manually implement equals, hashCode, and toString methods, taking into consideration the specific requirements and relationships of each entity, if necessary.

Please ensure that all relevant JPA entities are reviewed and updated accordingly to adhere to these recommendations.

Example:

Suppose we have the following User entity with associations:

@Data
@Entity
public class User {
    @Id
    private Long id;
    
    // Other fields and associations
    
    @OneToMany(mappedBy = "user")
    private List<Order> orders;
}

To address the performance and memory concerns, we can modify the entity as follows:

@Getter
@Setter
@RequiredArgsConstructor
@Entity
public class User {
    @Id
    private Long id;
    
    // Other fields and associations
    
    @OneToMany(mappedBy = "user")
    private List<Order> orders;

    // Manual implementation of equals, hashCode, and toString methods
    // Exclude associations from these methods if not relevant for equality or representation
}

Assignees: @dawciobiel
Due time: ASAP

Create a tutorial for working with Git and GitHub

The tutorial must include working on the project using the git tool and GitHub.

• includes naming conventions for issues
• includes naming conventions for pull requests
• includes naming conventions for branching
• proper convention of the commit description

Tests for the confirmUserRegistration method:

• Verify that the method successfully confirms user registration based on a valid token.
• Verify that the method throws an exception when the provided token does not exist.
• Verify that the method throws an exception when the provided token is not of the registration confirmation type.
• Verify that the method throws an exception when the token has already been confirmed.
• Verify that the method throws an exception when the user is already enabled.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

fill in your details, linking github data to discord required

Due to the end of spring boot support in version 2.7.0 by 2023-11-18, the project should be migrated to 3.1.0 whose support ends on 2024-05-18

In addition, it will also be a big plus for potential contributors who would like to join the project and work on new versions

Tests for the checkUserExists method:

• Verify that the method returns true for an existing user ID.
• Verify that the method returns false for a non-existent user ID.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Tests for the modifyUser method:

• Test the successful modification of user data and verify that it returns the correct data.
• Verify that the method throws an exception when the provided user does not exist.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

Klasa:
https://github.com/Simple-as-Coding/tutoring-platform/blob/main/src/main/java/pl/simpleascoding/tutoringplatform/repository/**UserRepository**.java

L:9
jest:
findByUsername()

powinno być:
findByUserName()

Unit test for the cleanExpiredTokens method:

• Mock the TokenRepository and UserRepository dependencies.
• Prepare a list of expired tokens with different types and confirmation statuses.
• Mock the behavior of the token repository to return the prepared list of expired tokens.
• Verify that the expired tokens are deleted from the token repository using the deleteAll method.
• Verify that the appropriate log message is generated for the deletion of expired tokens.
• Verify that the inactive users are deleted from the user repository using the deleteAll method.
• Verify that the appropriate log message is generated for each deleted inactive user.

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)

add 2 scripts (bash, powershell) that will execute the command like that

docker run -p 1080:1080 -p 1025:1025 maildev/maildev
but with the ability to be controlled by application.properties :
_
so it should look like that

docker run -d \
--name "$CONTAINER_NAME" \
-p $MAILDEV_WEB_PORT:1080 \
-p $MAILDEV_OUTGOING_PORT:1025 \
-e MAILDEV_WEB_USER="$USERNAME" \
-e MAILDEV_WEB_PASS="$PASSWORD" \
maildev/maildev

and catching possible errors related to running docker containers

-Create separated package for token feature
-Refactor Token feature scope to package default
-Refactor existing ExpiredTokensCleaningService to TokenService
-fix outside methods usage to be handled through Service ( TokenService )

Assignees:
Due date:

Create the content of a launch project instruction

• Create the content of a launch project instruction

Unit test for the findAllTeachers method:

• Verify that it correctly returns a page of users with the teacher role.
• Verify that it returns the expected RscpDTO status.
• Verify that it returns the correct message description in the RscpDTO.
• #157

instructions for the task
_use the convention //given //when //then
mock all injected dependencies with business logic using the Mockito library, e.g. UserRepository
try to use the BDD methodology, e.g. the assertJ library (optional)