From 40f869ee92fc824c0c0b1ee3545b19a09ad533fe Mon Sep 17 00:00:00 2001 From: sabinem <5292683+sabinem@users.noreply.github.com> Date: Wed, 22 Oct 2025 09:47:38 +0200 Subject: [PATCH 1/2] spec: move member questions to members --- docs/development/spec/src/members.md | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/docs/development/spec/src/members.md b/docs/development/spec/src/members.md index a338e727..a4a98755 100644 --- a/docs/development/spec/src/members.md +++ b/docs/development/spec/src/members.md @@ -130,6 +130,28 @@ To accept such an invitation is an action on the 4. The list of memberships with emails is returned. ```admonish question - - Should `User.id` be the DAC `admin`, or can any DAC `member` get the list of - members? + - Should `User.id` be the DAC `admin`, or can any DAC `member` get the list of + members? ``` + +## Email privacy questions + + - We decided that we do not notify the client when the email does not exist. + The [`POST /dacs/{id}/members`](#backend-secbackend-dac-add-member) endpoint returns the created object like every + other endpoints. This is a problem, because when the email does not exist, a + null UUID is returned. This can be used to know which emails exist and which + don’t exist. Potential solutions: + - Return nothing. + - Return the user without ID whether it exists or not. + - Return the full user, and assume that the endpoint is private and will + always get called by the front-end server. + - What do we do in general if a user does not have an email? E.g., in + `PATCH /dacs/{id}/members`, should we return the member without email or + display an error? Emails can be set as optional in Keycloak. + - Related with the two questions above: should we return dac members with + status pending? This is useful for notifying users that they need to accept + the invitation, but this reveals their ID and therefore reveals if their + email is in the system or not. + +-> For the MVP: this is fine as only DAC admins can access the endpoint. We + will discuss that in more detail later. -- GitLab From 61905e4106e674e29a0da826ce3ef23ed3d7f30f Mon Sep 17 00:00:00 2001 From: sabinem <5292683+sabinem@users.noreply.github.com> Date: Wed, 22 Oct 2025 10:39:00 +0200 Subject: [PATCH 2/2] spec: update submission spec --- docs/development/spec/src/submissions.md | 107 ++++++++++++++++++----- 1 file changed, 83 insertions(+), 24 deletions(-) diff --git a/docs/development/spec/src/submissions.md b/docs/development/spec/src/submissions.md index 6c5a56b4..c66f5847 100644 --- a/docs/development/spec/src/submissions.md +++ b/docs/development/spec/src/submissions.md @@ -1,5 +1,7 @@ # Submissions Management +## DAC member views submissions + ## Submission Review Process ```mermaid @@ -56,11 +58,90 @@ sequenceDiagram ## Create a Submission - +This happens externally at FHD Portal. A user creates a submission by choosing a +policy for a dataset. The submission id is created externally already. + +```mermaid +sequenceDiagram + participant FHDS as FHD Submitter + + box FHD Portal + participant FHD as FHD (External) + end + + box Dac Portal + participant DPBE as DAC Portal (BE) + participant DB as Database + end + + note right of FHDS: Enter Dataset at FHD portal
and list available policies + FHDS ->> FHD: connect + activate FHD + + FHDS ->> FHD: enter Dataset + + FHDS ->> FHD: list available policies + + activate DPBE + FHD ->> DPBE: GET /policies + activate DPBE + DPBE ->> DB: GET all policies + activate DB + DB ->> DPBE: return policies + deactivate DB + DPBE ->> FHD: return policies + deactivate DPBE + FHD ->> FHDS: display policies + deactivate FHD + + note right of FHDS: Create Submission for
a Dataset under a policy + FHDS ->> FHD: submit datasets with a policy + + activate FHD + FHD ->> DPBE: POST /submissions + activate DPBE + DPBE ->> DB: create submission in status pending + + activate DB + DB ->> DPBE: return success/error + deactivate DB + + DPBE ->> FHD: return success/error + deactivate DPBE + FHD ->> FHDS: return success/error + deactivate FHD +``` + +- Endpoint: `POST /submissions` + +- Content-Type: `application/json` + +- Usage: `FHD` + +- Input: + + - `submissionID`: ID of the submission to update. + - `policyID`: ID of the submission to update. + - `datasetID`: ID of the submission to update. + - `t`: access token containing the user info `User_id`. + +- Pre-Condition Checks: + + - Assert: `t` is valid and has the necessary scopes \[`1fb80d5f`\]. + - Assert: assert that the `policyID` points to a valid policy in the DB. + - Assert: that the dataset `datasetID` exists on FHD portal + - Assert: that the submission `submissionID` exists on FHD portal + +- Processing: + + - The `dac-backend` checks whether the policy is valid and dataset and + submission exist on FHD portal + - The `dac-backend` creates a submission with the status `pending` in the DB. + - The `dac-backend` returns a message of success ot error to the FHD portal. ## Get a Submission -**Backend API** +### Backend - Endpoint: `GET /submission/{submissionID}` - Content-Type: `application/json` @@ -103,25 +184,3 @@ sequenceDiagram with an empty `policyID` field instead, or should the endpoint only represent datasets that are part of the dac-portal ecosytem (i.e., from a submission)? - Up to FHD to decide. - -Email privacy questions: - -- We decided that we do not notify the client when the email does not exist. The - `POST /dacs/{id}/members` endpoint returns the created object like every other - endpoints. This is a problem, because when the email does not exist, a null - UUID is returned. This can be used to know which emails exist and which don't - exist. Potential solutions: - - Return nothing. - - Return the user without ID whether it exists or not. - - Return the full user, and assume that the endpoint is private and will - always get called by the front-end server. -- What do we do in general if a user does not have an email? E.g., in - `PATCH /dacs/{id}/members`, should we return the member without email or - display an error? Emails can be set as optional in Keycloak. -- Related with the two questions above: should we return dac members with status - pending? This is useful for notifying users that they need to accept the - invitation, but this reveals their ID and therefore reveals if their email is - in the system or not. - --> For the MVP: this is fine as only DAC admins can access the endpoint. We will -discuss that in more detail later. -- GitLab