as a user, I can get a list of audits submitted by an a small number of search parameters

[jadudm]

The minimal search has several parameters that want to be minimally validated on the frontend before being passed to the backend as a JSON object.

### Tasks
- [ ] <strike>design minimal search interface in Figma as "source of truth"</strike>
- [ ] <strike>update image on this ticket with link and shot of the Figma design</strike>
- [ ] implement search frontend that checks (described below) fields
- [ ] POST to Django containing a minimal object containing the parameters of the search

The interface will have a left-hand set of search terms, with a Federal warning modal occupying the body to start.

Interface elements

### UEI/EIN
- [ ] A multiline text field
- [ ] When user hits search, checks are applied
- [ ] Strip all non-number/non-characters
- [ ] Replace commas with whitespace
- [ ] Upcase the string
- [ ]  Split on all whitespace (space/newline/tab) to get a list of query terms
- [ ] Minimally clean at this point. To clean (but not check), filter so that all strings are either strings of length 9 or 12, and pass it back to the backend
- [ ] To minimally check, strings of length 9 must match `[0-9]{9}`, and strings of length 12 must be UEIs. We should have UEI regex code laying around in the frontend somewhere

We will not report errors to the user. If they throw garbage in here, we will filter it out and pass good data to the backend as best we can. We can ticket coming around to error reporting later, but for MVP, if they put garbage in, they will get no search results.

### ALN/CFDA
- [ ] Multiline text input
- [ ] Apply a sequence of filters; combine the resulting arrays from each filtering pass for a good result set
- [ ] Keep lines that are just a single-digit or two-digit number
- [ ] Pad all single digits with a leading zero
- [ ] Keep lines that are valid program numbers (the regex for this is floating around either in the Python code or in the Jsonnet validation schemas)

eg. in some language-ish

just_agency_numbers = map(pad_with_leading_zeros, filter(list_of_strings, lambda s: match(s, "{0-9}[2]")))
just_valid_alns = filter(list_of_strings, lambda s: match(s, VALID_ALN_REGEX)) 
pass_to_backend = just_agency_numbers + just_valid_alns

Per above, no error reporting. Just filter and send.

### Cognizant agency
- [ ] A single dropdown containing the valid agency numbers
- [ ] Default to "ANY"

This list is in our validation code and other places. Do not pass "ANY" to the backend; in other words, the default value should not ship; if they select a value, pass that in the object. It should be an ignored search term if untouched. It may be better practice to leave it blank as a default than to have the word "ANY"; that decision is in design/FE's hands.

### Audit Year
- [ ] Checklist group, multiselect
- [ ] 2023 - 2018
- [ ] No defaults selected

Pass, as an array, the years selected.

### Acceptance date
- [ ] Start date, end date
- [ ] Make sure start is before end
- [ ] If only a start date is given, pass it back. Populate end date with October 1, 3000. 
- [ ] If only an end date is given, pass it back. Populate start date with October 1, 1000. 

The theory here is the backend should be able to trust that if the user sets any date, that both fields will always be populated. We will come back to this if the backend/DB team later say that this causes problems for optimization.

### Modal Federal warning
- [ ] The body should default to a `div` or container that contains the warning about data/usage with an `Accept` button of some sort. On accept, disappear the div.
- [ ] If it is *easy*, we can add a cookie. If the cookie does not exist, show the modal. If it does exist, and is less than or equal to 30 days old, then do not show the modal. If it does exist, and is more than 30 days old, show the modal again.

### Search button
- [ ] The button is always enabled
- [ ] If the button is pressed, and no terms are selected, display text in the body to the effect of "no query terms given, no search performed". Copy to follow.
- [ ] If the user inputs a set of terms that produce no results, the backend will return that no results were found.
- [ ] https://github.com/GSA-TTS/FAC/issues/1232

We will not attempt to disable the button based on search term contents. Instead, we will check (in JS) that the query object, when gathered up, is empty. If it is empty, then we display a warning. This saves sending an empty search query.

See the backend breakout for sync with backend.

### Results / Pagination
- [ ] The backend sends all results for a query as a JSON array of result objects
- [ ] Frontend paginates at 20 results
- [ ] Column-sorts will be over all results

[jadudm]

For now, the frontend team should develop against the sketches provided. We'll revise the look-and-feel of the page later; the elements will not change. So, please use best judgement for your initial implementation. You won't have a "Figma source of truth" at the moment.

[tadhg-ohiggins]

This is where we landed 2023-06-13:

1. User interacts with frontend to create search parameters.
2. Frontend converts the user inputs to a request to Django. This should be bookmarkable, and so should probably be a GET request.
3. Django receives this and deconstructs it, possibly adding in anything that should be there by default, and translates it into something to query PostgREST with.
4. The easiest way (I think!) to make the query to PostgREST is to use the PostgREST GET query format. So we do this from Django, get the results back, and return them to the frontend.
5. The frontend displays them to the user, possibly (?) handling pagination, etc.

Django will do minimal validation, but may throw out some invalid fields.

[danswick]

👉 https://github.com/GSA-TTS/FAC/issues/2236