Add the ability to use PSCID in place of CandID in the candidates API.

[driusan]

This adds the ability to use PSCID instead of CandID in the URL for
the v0.0.4-dev version of the API. All endpoints under /candidates/{candID} should now accept /candidates/{PSCID} instead, as long as there's one single unique PSCID with that identifier.

This was requested by the HBCD project, but after talking to @ridz1208 is a common request for many projects, so I've added the functionality to v0.0.4-dev of the API.

[driusan]

@xlecours Can you help me update the swagger schema and review? I looked into modules/api/static/schema-v0.0.4-dev.yml to try but it's not clear to me how to update it there..

[xlecours]

That versioning is really annoying. I think it could go in v0.0.3 since it does not break anything.
Regardless of my opinion, yes, I'll look at the schema.

[xlecours]

@driusan If you want to add in 0.0.4-dev, then you need to add the part that differ from 0.0.3 in modules/api/static/schema-v0.0.4-dev.yml (with the components definitions and all.) Otherwise, I would change candid for id at https://github.com/aces/Loris/blob/main/modules/api/static/schema.yml#L236 and every other instances in the path, as well as the parameter definition for each eandpoint.

[driusan]

It would break scripts that assume it's the case on v0.0.3 on instances where it's not the case.

[driusan]

But maybe it would be reasonable to release it as v0.0.4 and remove -dev?

[xlecours]

But maybe it would be reasonable to release it as v0.0.4 and remove -dev?

And remove v0.0.3 ? I don't think we can afford to maintain multiple versions of the api.

[driusan]

I incorporated the changes from the v0.0.4-dev into the 0.0.3 schema and then copied it back on top of the schema-v0.0.4-dev.yml file because 1. it more accurately represents what the endpoints are in v0.0.4-dev and 2. nearly every endpoint would have had to be copied anyways.

I had to do the candid->id changes manually because "candid" is a substring of "candidate" so it wasn't easy to do with a regex without breaking other things. It's possible I screwed something up.

I don't understand why we would remove 0.0.3 once 0.0.4 is released. It's 99% unchanged endpoints and usually only new ones are added. People are using the API and I don't see why we would need to remove it or have much maintenance to do before something breaks.

@ridz1208 I think @xlecours is away for a bit, can you review this now that the swagger schema is (hopefully) updated?

[ridz1208]

Other than the versionning that is triggering me. I think this PR looks fine, the only usecase that this would not work is if the a study configures the PSCID to be formatted exactly like our CandID and it happens that one of the PSCIDS has a matching candID. I would say the odds of that are very low (I only know 1 study that uses that format) but a failsafe could be added to confirm that the PSCID configuration is NOT 6 digits

[xlecours]

I think it should be mentioned that in the eventuality of a candid-pscid collision, the client should make sure that the returned candidate data matches the request.

[driusan]

@xlecours @ridz1208 added a note.. is this good to be merged now?

[ridz1208]

I already approved. all good here

[xlecours]

I don't approve the feature not the schema file changes but the code is ok. And, on a side note, this introduce the first sql statement in the api module.

[driusan]

Good enough for me!