Feature delete user complete

[Vasilijez]

Closes #6

My biggest difficulty was determining which APIs should include a logical deletion check, whether for user deletion or room deletion. Ideally, all APIs should be updated, but I wasn’t entirely sure about that, as it would require many changes and I was concerned about dependencies. Therefore, I focused on the APIs that are directly exposed by the webapp.

I am ready to update all APIs, or specific ones if necessary or as you recommend.

Part of:

• Feature delete user complete web-app#42
• feat: Support logical deletion within APIs reservation-service#24
• Feature delete user complete #40
• Feature delete user complete room-service#32

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)
17.2% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[magley]

Scenario:

• Host H has a room R
• Guest G creates a reservation request for R
• H deletes his account
• This passes, but the reservation request for R is not deleted
• In the web app, G can see this request and click the link to room R, which has been deleted

[Vasilijez]

Scenario:

• Host H has a room R
• Guest G creates a reservation request for R
• H deletes his account
• This passes, but the reservation request for R is not deleted
• In the web app, G can see this request and click the link to room R, which has been deleted

Okay, I made some changes related to this in other PRs. Please test it carefully.

[magley]

Shouldn't the FindById method return 404 if the user is deleted?

Since we do logical deleting now, it'll return a deleted user. Do you check for deleted users elsewhere? Come to think of it, you do in reservation-service. Should we leave it as-is, then?

[Vasilijez]

Shouldn't the FindById method return 404 if the user is deleted?

Since we do logical deleting now, it'll return a deleted user. Do you check for deleted users elsewhere? Come to think of it, you do in reservation-service. Should we leave it as-is, then?

I really need to be careful if I do it (and that’s the reason why I skipped it), because it’s a core method and consequently an API that’s used very often. So if we do it, we need to thoroughly check its role everywhere it’s used. For now, most of the APIs that are used by our web app are covered.