Fix RegisterPassViewSet.destroy logic and add unit tests

[GonzaloMachado]

Fix Logical Error in RegisterPassViewSet.destroy Method and Add Corresponding Unit Tests

Description

This pull request addresses an issue in the RegisterPassViewSet class where the destroy method does not delete a registration when one exists. The current logic incorrectly returns a 200 OK response without performing the deletion. The changes made include:

• Correcting the logic in the destroy method to ensure that the registration is deleted when found.
• Adding unit tests to verify the correct behavior of the destroy method.

Changes Made

Corrected Logic in destroy Method:

• Changed the condition from if registration: to if not registration: to properly delete the registration if it exists.
• Ensured that a 200 OK response is returned when no registration exists, as expected.

Added Unit Tests:

1. Test for Existing Registration: Verifies that the registration is deleted successfully if exists.
2. Test for Non-Existing Registration: Verifies that a 200 OK response is returned when the registration does not exist, and ensures that no registrations are deleted accidentally.

This commit addresses issue #33.

[patroqueeet]

lgtm.

just wondering: if not found: should we return a 404? would that go along with the apple spec?

[GonzaloMachado]

lgtm.

just wondering: if not found: should we return a 404? would that go along with the apple spec?

That's a good question.

Based on the Apple documentation, the expected response codes for the unregistration endpoint are 200 for successful unregistration and 401 for unauthorized requests. A 404 response is not explicitly mentioned. I haven't tried responding with a 404 to see if Apple is going to be in the mood for that. 😄

[patroqueeet]

lgtm.
just wondering: if not found: should we return a 404? would that go along with the apple spec?

That's a good question.

Based on the Apple documentation, the expected response codes for the unregistration endpoint are 200 for successful unregistration and 401 for unauthorized requests. A 404 response is not explicitly mentioned. I haven't tried responding with a 404 to see if Apple is going to be in the mood for that. 😄

then I'd go for it. seems to be the better aka correct practice. @NachE @alexandernst ?

[alexandernst]

+1. I'd stick to what Apple expects. Even if you tested it and it worked today doesn't mean Apple won't change their mind and break it tomorrow. Returning always 200 seems fine to me.

[alexandernst]

Btw, this PR needs to be updated because of a conflict caused by the merge of the other PR

[NachE]

Agree, 200 OK is correct for authorized but non existing pass