feat(recap): Add suport to parse ACMS attachment pages #3393
Conversation
ERosendo
changed the title
ERosendo
force-pushed
the
feat-add-support-to-parse-attachment-pages-from-acms
branch
3 times, most recently
from
7fb2719
to
a58920e
Compare
ERosendo
force-pushed
the
feat-add-support-to-parse-attachment-pages-from-acms
branch
from
a58920e
to
855aaf6
Compare
Adds a new parameter to the merge_attachment_page_data method and tweaks the merge mechanism to integrate ACMS attachment pages into their corresponding docket entries.
ERosendo
force-pushed
the
feat-add-support-to-parse-attachment-pages-from-acms
branch
2 times, most recently
from
0d221ca
to
4ae06ee
Compare
ERosendo
force-pushed
the
feat-add-support-to-parse-attachment-pages-from-acms
branch
from
4ae06ee
to
5214801
Compare
* Updates logic to handle successful marking of the processing queue using the new method arguments. * Implements the `associate_related_instances` method for additional functionality.
|
@grossir, can you please review again before I take another look? It's been a month or two and it looks like we've got some changes. Thank you! |
| "docket_entry", "docket_entry__docket" | ||
| ) | ||
| .filter(**params) | ||
| .afirst() |
There was a problem hiding this comment.
Are you sure the first will be the desired RD? Note that the RecapDocument model has this Meta attribute ordering = ("document_type", "document_number", "attachment_number")
There was a problem hiding this comment.
Are you sure the first will be the desired RD?
Yes, we use attachment #1 as the main_rd for attachment pages. Unlike district court pages, ACMS pages only have attachments. Here's a comparison:
| District court | ACMS |
|---|---|
 |
 |
Note that the RecapDocument model has this Meta attribute ordering = ("document_type", "document_number", "attachment_number")
This won't be an issue because ACMS documents within an attachment page share identical pacer_doc_id, document_type (ATTACHMENT), document_number (the entry number), this ensures the queryset is ordered with attachment #1 appearing first. Here's an example:
| pacer_doc_id | document_type | document_number | attachment_number |
|---|---|---|---|
| 583c6255-3fd2-ed11-b596... | 2 | 29 | 1 |
| 583c6255-3fd2-ed11-b596... | 2 | 29 | 2 |
…S types This commit updates the ProcessingQueueSerializer to include validation for ACMS types. This ensures data integrity and prevents potential errors when processing ACMS-related data.
|
The model changes are noops. Would it be possible to rename them to something like 123_add_upload_types_noop.py/sql, so that those of us doing deployments (and those inspecting migrations later) can see that they're not changing the DB? I think this is in our dev guide as a best practice, but if not, we should probably add it. |
Sure!
You're right, it is described in the "Steps to making new migrations" section of the Database Migrations wiki page. |
This PR introduces the logic to process attachment pages from ACMS. Here's a breakdown of the key changes:
New Upload Type: A new upload type named
ACMS_ATTACHMENT_PAGEis added to theProcessingQueueandpacerhtmlfilesmodel.A new helper method
process_recap_acms_appellate_attachmentis introduced. This method encapsulates the logic for parsing, processing, and merging ACMS attachment pages.The
PacerDocIdLookUpSerializerclass is updated to include theacms_document_guidfield in its response. This field is crucial for matching documents within the attachment page and generating the recap icon in ACMS.Factories are added to mock the dictionary returned by Juriscraper methods. Additionally, tests are included to verify the functionality of the new features.