Implement Danger as automated review. Already happened conversations resulted in the DangerJS implementation.
This issue will be used for the planning of the Danger Checks

General

• Warn if no assignee is set, an assignee makes it clear, who is responsible for merging after the reviews happened
• Warn if no labels have been set, labels indicate the type of the change
• Warn if no milestone is set, a milestone indicates the release the change should get published in
• Warn if the PR has the "better description" label to update the description of the PR
• Message if the PR modifies the tooling and is from an outside contributor
• Warn if the PR modifies the .idea directory and is from an outside contributor (message if collaborator)

Linter

• Fail if a file is missing a newline at the end
• Fail if a file uses wildcard imports
• Fail if a file name does not comply with /[a-z0-9]+\.[a-z0-9]+/i

... look into the other issues, where features are planned
The "management system" provides some admin actions

• delete entire user data, this includes all data, that is user related: application, history etc.
• fetch all user data, this data is fully represented, so no other requests are needed
• block an user from creating applications
• unblock user
• get block status
• swagger docs

This issue is used to plan and track the status of this features:
Add some essentially template endpoints:

• Create -> create a template
• Replace -> replace a template by it's name
• Get -> get a template by name
• List (names) -> list names of all templates
• Delete -> delete a template by it's name

Also

• Swagger generation
• Swagger description
• Ci for test

Add a better readme for this project, containing some informations:

• the goal of this project
• informations about the features and structure of the backend
• usage (docker etc)
• module informations
• contributing
• short license reference

This issue was created to plan and track the current status of the implementation of some events, which are required to guarantee the core functionality of this backend.

• application created
• application deleted
• application processed

More informations about applications: #6

Currently the CI Workflow does not run for a PR from a fork. To fix this, a new workflow with the same configuration should be created.

That workflow needs a condition, so it only runs if the PR is from a fork and not from an inside collaborator

The CodeQL Action should be set up to perform security scans

For the core functionality of this backend there are some application queries required.
This issue is used to plan and track the current status of the implementation.

• create an application
• edit (current) application
• delete an application (id)
  - [x] get application (id/period of time in which the application was processed)
• get all user applications
• process an application

An Application is a filled template, that belongs to a user. A user may only have one current application, that can be processed by a moderator (Rejected, Accepted). If an application is rejected, then its status changes to "rework" and the user is able to rework the application. After processing an application becomes immutable and can be get via its id directly or by a period of time in which the application was processed.

The dto_common project will be deployed as Maven package

After some internal discussions, we decided to use PostgreSQL as our database. Our data can be easily represented in a relational database, so we would also enjoy the benefits of a schema based database, this would support the data consistency.

Problems with MongoDB (and Micronaut):

• lack of integration (currently under development)
• lack of migration tools, Mongock uses reflections and has limited bean injection
  - no data (format) validation

All these problems can be easily solved by using an SQL database, like PostgreSQL.

Dependabot should be configured to create dependency update PRs

Running the Test Suite directly without checking the health of the backend container before wastes a lot of time before the logs are displayed to show the error on startup.

Adding a healthcheck before running the test suite will solve that as "fail-fast"

This issue is used to track and plan the development of:
Add a few essentially events:

• Template updated
• Template deleted
• Docs

This issue was... you know the text, if not check the other issues!
Some history events:

• entire user history deleted
• specific entry deleted

more infos: #12

The backend project will be deployed as Docker image

... you know what for this issue is

• user data deleted
• user block status changed

for me informations look into: #15

Add response message localization based on a http header

The history allows to get or delete an older application of a user by it's user id and timestamp.
This issue contains informations and the current status of the implementation.

• get all application timestamps of an user
• get a specific application of an user by timestamp
• delete the entire history of an user
• delete a specific application of an user
• swagger docs

Waiting for Micronaut's fix on CrudRepository#find issue.
Or I'm missing something :D