Closed jcushman closed 10 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
aaa250b
) 63.54% compared to head (0da1916
) 63.60%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR tries to handle the tricky issue of how to find one case in the static file export from another.
Problem: If you have a case like /us/123/cases/0012-01.json that cites to case id 4567, or a list of case IDs in /us/123/CaseMetadatas.json, it's hard to find the files that contain the data for those cases.
Solution: Everywhere that we have cases referred to by ID, also refer to them by path. A path for a case is like "/us/123/0012-01", or just "0012-01" if the reporter and volume are already implicit.
So:
"file_name": "0012-01"
field. This makes it possible to jump from CaseMetadatas.json to the associated json or html file, allowing the frontend to render the list of cases in a volume for example."cites_to": [{"case_ids": [1,2,3...]}]
, add a field for each citation like"case_paths":["/us/1/0001-01", "/us/2/0002-01", ...]
that parallels"case_ids"
.href="/citations/?q=123 Wtf. 456"
. (This is common for statutes and regulations).href="/us/1/0012-01" data-case-paths="/us/1/0012-01,/us/1/0012-02"
.Deployment notes:
Case paths are hard to calculate, because you have to add an increment for two cases starting on the same page of the same book, like
0123-01
and0123-02
. So this PR adds a column in a migration to store that calculated string on CaseMetadata, and after deployment we should runfab set_case_static_file_names
(which runs in a tqdm loop rather than in celery) before redoingfab export_cap_static_volumes
for the non-redacted jurisdictions.