[Task]: (Backend) Setup an endpoint that returns all versions of an opportunity

[chouinar]

Summary

This would be a sub-endpoint under the opportunity endpoint, something like GET /opportunity/<opportunityId>/versions and maybe a specific version one as GET /opportunity/<opportunityId>/version/<versionId?>.

We should figure out how the response would be structured, likely just a list of values similar to our GET endpoint. Note that versions are.. odd in that only ~80% of the data is versioned. The top-level opportunity info isn't versioned in the current experience (although does have versions), so we'll need to sort that out.

Acceptance criteria

No response

[chouinar]

Looking into this, I found that the existing version logic is more complex than I would have expected. Here is roughly what the current algorithm is:

• Fetch all the forecast/synopsis history records (it seems like it pairs them by revision number, although I don't think that matters?)
• For each historical forecast/synopsis record:
  • If the "current" forecast or synopsis is null, drop the history records - this would only matter if the "current" were marked as deleted with our approach.
  • If the historical record is marked as deleted, drop it
  • If the historical records posting date is null, drop it
  • If the historical records create date is before its own posting date, drop it (so, effectively, don't show anything created before it was posted, even if that post date has passed)

A few things we'll need to account for:

• We don't maintain a current opportunity summary for both forecast and non-forecasts. It isn't too difficult to account for this as we can just order by revision number.
• Because our create/post dates aren't both dates, and the create date is actually a timestamp, we might have some odd off-by-one issues to account for with timezones.

[chouinar]

There are two additional complexities ontop of what I wrote above (debateable whether these are intentional or bugs?)

If an opportunity has forecast and synopsis records, whichever one is deemed the current one will display, but the other "current" will just not appear at all, but the history records for both types will. So if the current synopsis is 3, and the current forecast is 2, we'll see Synopsis 3, 2, 1, BUT for forecast we'll only see Forecast 1. This seems.. unnecessary? Most of the time the forecast does actually get updated after the fact to automatically set an archive date. Not terribly exciting info, but no reason to hide it.

---

I can't confirm this with 100% certainty as I didn't download the required data before our stoppage - but it seems like there is one other case where a forecast/synopsis won't appear in the history. The way it fetches these is weird, it actually gets a list of Opportunity History + Synopsis Hist + Forecast Hist records grouped by the revision number. The revision number is updated on an opportunity for.. I actually don't know the exact reasons, but based on what I'm seeing, the revision number of an opportunity increases for every record added to the synopsis/forecast history tables (although there is likely more that does that).

So, with those history tuple-like objects, what would happen if the opportunity history record was marked as deleted (or just actually deleted)? Presumably, that record wouldn't get returned at all since the query looks to be specifically for the opportunity history, not the synopsis/forecast history. Which means, if the opportunity records ever get deleted, the current system doesn't return those versions of the history records. Is this intentional? Why are opportunities organized like that with revision number?

[chouinar]

So, thinking through how we might do this right now

• I'm going ignore anything with the weird opportunity history join filter right now. We don't have that data, and I think I need to ask around for more context to do anything there.
• I feel like the other weird issue where the current synopsis/forecast isn't included in the history if its not the "true" current doesn't make any sense. Just seems like a mistake.
• Actually implementing this - I think is doable, debatable whether we do the filtering in-code or in the queries to the DB. I think in-code might be simpler. The actual query to fetch this is inconsequential in performance (select * from table where opp_id = x), and iterating over that list is fine.
• This only is going in the GET endpoint, no need to add any of this to search at the moment. I don't think the current approach even does that (the only "historical" value it adds is the opportunity number history).

[acouch]

Issue migrated to hhs/simpler-grants-gov#2079