Edpub 1730 fix broken endpoints

[ckd002]

Description

Fix the following endpoints that were identified as being broken during the review of all API endpoints.

• /api/data/submissions
• /api/submission/review
• /api/submission/restore
• /api/submission/createStepReviewApproval

Linked JIRA Task or Github Issue

JIRA Task: EDPUB-1730

Types of changes

What types of changes does your code introduce to Earthdata Pub (EDPub)?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if adding or updating the existing documentation resources)
• Other (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the Contributing Guide
• I have updated the CHANGELOG
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added the necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Validation Steps

This will help us get a jump start on validating your PR by describing the steps to replicate
and validate the expected behavior. (For an example of good validation instructions, check out Bryan's Bouncy Ball PR.)

1. Make sure all merge request checks have passed (CI/CD).
2. Pull related branches locally.
3. Navigate to the swagger and authenticate
4. Test the /api/data/submissions endpoint and verify that the query now runs successfully
5. On the swagger page, ensure the following endpoints are no longer listed in the service section

• /api/submission/review
• /api/submission/restore
• /api/submission/createStepReviewApproval

6. Test the /api/data/submission/operation/review endpoint and verify functionality still works as expected
7. Test the /api/data/submission/operation/restore endpoint and verify functionality still works as expected
8. Test the /api/data/submission/operation/createStepReviewApproval endpoint and verify functionality still works as expected

Further comments

Notes on this work:

• /api/data/submissions

  • dashboard actions that referenced this endpoint were all removed as part of EDPUB-1710 so we could consider removing this endpoint all together, but for now it was simply fixed to include the daac_name option. I chose to fix it rather than remove because the endpoint calls the submission.findAll query and while it doesn't appear to be used anywhere, we have findAll queries for most other handlers, so it made sense to leave it for consistency.

• /api/submission/review

  • This endpoint is being removed because it feels like approvals should be happening by individuals not a service account. The way this endpoint is handled on the backend assumes a user is making the decision so the implementation fails when done through a service account. I thought about how we could work to update this to allow somethings to be able to be handled by a service account (I.e. steps that don't require multiple approvals), but in the end decided against it because I felt it would create unnecessary complexity and would require some additional design thought into how we handle which things a service account can and cannot approve ( i.e. a service account basically has admin approvals so could approve/reject both daac steps & uwg steps type thing)

• /api/submission/restore

  • This endpoint is being removed because there isn't a strong enough use case to justify changing how we handle our service secrets. The service credentials get deleted as part of the withdraw process (EDPUB-1555). Because of this, there are no valid service credentials that can be used to restore the submission. Users wishing to restore a submission that was withdrawn will have to do so using the dashboard. Note - restoring the submission will not re-instate the service secrets. Once deleted those are gone. Currently a user would have to move the submission back to the state where a service key gets created and then move it forward to the current desired state.

• /api/submission/createStepReviewApproval

  • This failed because it tried to add the service authorizer as the "submitted_by" value which is a no-go because that field is expecting a UUID (foreign key referencing edpuser)
  • Possible solutions considered:
    • deletion - easiest, simply can't add a reviewer programatically (Option we went with)
    • create a "service user" - a generic user account to specify that it was created using a service account. Would mean an extra not real user account to exist in the system and may make some of the templates read a little bit odd. Also not sure what that would do to triggered emails.
    • require the endpoint to take a user as input that can be used in the field - Introduces the fact that they will be hardcoding a user and we have no proof that said user has actually authorized anything. Would also require vetting that whatever they pass is a valid user somehow.