feat: Add mongodb as a default database for application

[mimotej]

Related issues

Resolves #60

Type of pull request

• New feature
• Bug fix
• Refactoring
• Feature update
• Other

Describe your PR in detail

This PR adds mongodb database as a default database for the application. It utilizes mongodb atlas shared tier since it is fairly generous, later with the application would grow too large we might want to reconsider alternatives...
It uses Prisma as ORM
Also adds new states for status -> removed and banned, where removed users can reverify but banned users can't.

[github-actions]

Hello 👋, thank you for opening new PR to OqixTS 💗

Please, wait till somebody will review your PR.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
28.8% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[mimotej]

Ok I think it is ready for the review.
/cc @xvanick1

[xvanick1]

Suggestion for the possibility of re-verifying with the requirement of deleting old verification assigned to the thesis. Request to add the date of verification to the user object.

[mimotej]

Suggestion for the possibility of re-verifying with the requirement of deleting old verification assigned to the thesis. Request to add the date of verification to the user object.

Reverify option is little bit complicated since we need to define when is user able to reverify - For example there is big difference when the user is kicked from the server and when he leaves on its own. Is only situation when he can reverify when he leaves on its own or do we want to have option to "lift the ban". If the second option is true, then I would suggest leaving it for now and making it separate feature.

As for the the date of verification. Do you have something in mind how we would use it? Because first of all I would like to keep amount of data we store to minimum (mainly to protect students) and we also have currently quite a few people who are already verfied therefore simplest thing would be to add same date to each one, and I do not find that too useful 🤔 .

[xvanick1]

Suggestion for the possibility of re-verifying with the requirement of deleting old verification assigned to the thesis. Request to add the date of verification to the user object.

Reverify option is little bit complicated since we need to define when is user able to reverify - For example there is big difference when the user is kicked from the server and when he leaves on its own. Is only situation when he can reverify when he leaves on its own or do we want to have option to "lift the ban". If the second option is true, then I would suggest leaving it for now and making it separate feature.

As for the the date of verification. Do you have something in mind how we would use it? Because first of all I would like to keep amount of data we store to minimum (mainly to protect students) and we also have currently quite a few people who are already verfied therefore simplest thing would be to add same date to each one, and I do not find that too useful 🤔 .

In my opinion only re-verification when user leaves server should be available, as currently in this case, the record is still in database.
I thought a bit more about the re-verification feature. Discord has features kick & ban, as you mentioned. Afaik, kick is temporary, and ban is permanent. Therefore, every time user is kicked/is banned or leave the server, their verification should be automatically revoked in the database. Because if their kick period has ended, or ban is revoked, they should be able to join the server and verify again. I am unsure if this kind of automatization on "leave" is possible, but as you mentioned, this is a different feature.

Regarding the second request, I see it useful for security reasons when auditing suspicious behaviour... for example cases when there would be some leak from the server, we can filter out users verified in that period and check their behaviour about the leak.
For the users that are already verified, we can use the date of joining the server as this is available by default or just keep the field empty in their case.

[mimotej]

Converted back to draft since I am finishing the work on kicked and banned reverification and needs little bit more work.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[mimotej]

Now we have also states removed and banned. These states work this way:
removed -> user kicked, left or ban was removed - user can verify again (also new user can verify using proper credentials.
banned -> user is not able to verify again.
verified -> no other user can verify using these credentials

[xvanick1]

/lgtm