Code cleanup / dead code removal

[jadudm]

What what?

Let's remove some code that is no longer in use.

Candidates

### Tasks
- [x] api
- [x] data_distro: https://github.com/GSA-TTS/FAC/pull/3995
- [ ] report_submission + audit
- [x] data fixtures *everywhere*
- [x] Removed dead code : https://github.com/GSA-TTS/FAC/pull/4109

Notes

• report_submission + audit: Might involve moving URLs up to top-level.
• api: some parts need to be kept
• data_distro: possibly nothing needs to be kept
• cms: probably not needed at all (was for possible web content)
• data fixtures: what? why? where? for whom? Should we send some of them a card?

[timoballard]

The pre-SAC form has 3 steps:

eligibility - basic questions that determine whether or not you should be submitting

• Frontend template
• When a user clicks Continue, a Javascript handler submits the form. The form data is received by a Django view in the report_submission app, which forwards the form data to the eligibility-check function in the api app. This function uses the EligibilitySerializer to deserialize and validate the form data. If valid, the data is saved to the user’s UserProfile. The user is then redirected to step 2.

auditee info - UEI, audit period start/end dates

• Frontend template
• When a user enters a UEI and clicks Validate UEI, a Javascript handler passes the UEI to the backend with an ajax call to /api/sac/ueivalidation. The view for this endpoint is a Django REST Framework (DRF) API view.
• The use of DRF in the FAC application dates back to the original architecture, which intended to pair a static frontend with an API-driven submission process. This approach was eventually scrapped in favor of a more traditional Django application. The UEI validation endpoint should be the only DRF endpoint still in usage.
• When a user enters the fiscal period dates and clicks Continue, a Javascript handler submits the form. The form data is received by a Django view in the report_submission app, which forwards the form data to the auditee_info_check function in the api app. This function uses the AuditeeInfoSerializer to deserialize and validate the form data. If valid, the data is saved to the user’s UserProfile. The user is then redirected to step 3.

access - names and emails for submission editors and certifiers

• Frontend template
• When a user clicks Save and create audit, a Javascript handler submits the form. The form data is received by a Django view in the report_submission app, which forwards the form data to the access_and_submission_check function in the api app. This function uses the AccessAndSubmissionSerializer to deserialize and validate the form data. If valid, the SingleAuditChecklist object is created and persisted to the database, along with the necessary Access objects, and the UserProfile data is cleared.

[timoballard]

Going forward...

The api app is used in a couple of ways:

• there is a DRF view that performs UEI validations against SAM.gov. This view is called from step 2 of the pre-SAC form.
• there are DRF serializers that are the mechanism for validating the form data from each of the 3 pre-SAC steps.
• there are functions (1, 2, 3) that perform the business logic of validating the pre-SAC form data (using the above-mentioned serializers) and persisting the submitted data to the database. These functions are called from the corresponding views in the report_submission app.
  • Things were setup this was because when we switched from an API-driven submission process to a traditional Django application, we briefly attempted to continue support for API submissions, and so the business logic behind the pre-SAC form was implemented behind pure python functions in the api app so that they could, in theory, be called from both API and Django views.
  • That said, the DRF API has not been maintained and should be removed. If we wish to enable an API-driven submission workflow in the future, we would be better served starting from scratch, as the DRF API has drifted dramatically from the current state of the application.

Removing the api app will have to be done gradually and with care, as it still houses much of the pre-SAC business logic.

[danswick]

We're going to punt on combining the audit and report_submission applications for now.