feat (challenge) deleteChallenge function added to challenge service

[JungleGiu]

📍Context

Related subissue

In this task As a mentor, I can to delete a challenge
we are aiming to create a new functionality for the authenticated mentor user, who could be capable of delete a challenge from the DB.
After considering the possible consequences in the way data is related the team decided to proceed and the function appointing to the existing endpoint DELETE /itachallenge/api/v1/challenge/challenges/{challengeId} was created in the challenge service

✅ What's done

• deleteChallenge() function was created in challenge.service.ts with appropriate error handling
• test coverage is been added for he new function

🔍 Proof

Notes

The function is still not being called since this would be out of scope for this subissue, but the integration in the challengeForm component is next. to come in IT-Academy-BCN/ita-challenges#252

[polserrano8]

No he visto nada que me rechine en el código y la IA tampoco ha dado cosas a corregir que sean en este scope. Buen trabajo :)

[ivilarop]

The DELETE endpoint for challenges in back doesn't validate the user's role. An issue needs to be created to secure it. Have you discussed this with the back-end developers?

[otrocadev]

Hello Ivan, we have talked about that. Our approach is that the user won't be able to use this endpoint if it is not a mentor. That's becaouse the form where the button for action will be is already in the same page as the form editing. So technically the approach is the same as now with thye editing permisions.

[ivilarop]

I understand the reasoning, but UI-based security isn't enough. Any user could directly call the DELETE endpoint without going through the form, for example, from Postman or curl. Role validation needs to be on the back end, regardless of what the front end does. Since the back end hasn't identified this need, it would be good to bring it to their attention so they can create a technical debt.

[JungleGiu]

Yes we discussed the issue and since the ui of editing it's only accessible from a admin role, we talked about maintaining the same functionality. However I understand a more solid approach is recommended, I suggest to put a limitation in the next task , where we can verify the user role before triggering this function, that should be as abstract as possible in case of future backend role limitation implementations.

[JungleGiu]

Totally agree, i'll bring this issue to the attention of backend team

[otrocadev]

Should we also approach how this is handled with the edit process? I think the permissions and implications should be the same as the user role that shold be able to perform the action is the same.

We can see if this is already considered on the edit action of the same form so we can either repply the approach with the delete permission or to either make also a tech debt on this case scenario as well.

[ivilarop]

I understand the reasoning, but UI-based security isn't enough. Any user could directly call the DELETE endpoint without going through the form, for example, from Postman or curl. Role validation needs to be on the back end, regardless of what the front end does. Since the back end hasn't identified this need, it would be good to bring it to their attention so they can create a technical debt.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[carlosPc1987]

I’ve added the tech debt in the link after reviewing the conversation.

Technical debt created
Backend role validation for the DELETE challenge endpoint is now tracked as technical debt:

IT-Academy-BCN/ita-challenges#263

Once the version and CHANGELOG updates are done, this PR is good to merge from my side.

Great work, everyone