vocdoni / saas-backend / 28178332752

63%

push

github

feat(api)!: address processes by Mongo ObjectID in status/results/metadata (#551)

* feat(api)!: address processes by Mongo ObjectID in status/results/metadata

PUT /process/{processId}/status, GET /process/{processId}/results and
GET /process/{processId}/metadata parsed {processId} as the 64-hex on-chain
election id, while GET/PUT/DELETE /process/{processId} and .../publish parsed
it as the 24-hex Mongo ObjectID. The same path segment meant two different
identifiers, so e.g. GET /process/{onchainID} returned "invalid process ID".

Make all three look the process up by its ObjectID (a.db.Process) and use the
stored process.Address for the Vochain call, matching the rest of the process
API. results/status now require the process to be published (it has an Address).

The 64-hex on-chain id stays only where a voter needs it to sign/verify a vote:
POST /process/{processId}/vote, POST /process/{processId}/sign-info, and the
bundle sign/check bodies.

BREAKING CHANGE: status, results and metadata now take the 24-hex Mongo
ObjectID in {processId}, not the 64-hex on-chain election id.

* feat(api): accept Mongo ObjectID for process sign-info (keep on-chain id)

POST /process/{processId}/sign-info now resolves {processId} as the 24-hex Mongo
ObjectID (a.mainDB.Process) and uses the looked-up process.Address for the CSP
lookup and nullifier - consistent with status/results/metadata.

Exceptionally, and unlike those three, it ALSO still accepts the 64-hex on-chain
election id directly, to avoid breaking voter clients that already hold it (a
valid ObjectID is exactly 24 hex chars, so it never collides with the 64-hex id).

TestProcessReadProxies now asserts both forms return the same consumed address
and nullifier.

32 of 43 new or added lines in 3 files covered. (74.42%)

9816 of 15811 relevant lines covered (62.08%)

44.63 hits per line