Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replicate RECAP PDF uploads to subdockets #4826

Closed
albertisfu opened this issue Dec 16, 2024 · 3 comments · Fixed by #4857
Closed

Replicate RECAP PDF uploads to subdockets #4826

albertisfu opened this issue Dec 16, 2024 · 3 comments · Fixed by #4857
Assignees

Comments

@albertisfu
Copy link
Contributor

In #4665 attachment pages that belong to doppeldockets are replicated across all subdockets.

This approach should also be applied to PDF uploads.

@mlissner
Copy link
Member

There's an opposite direction to this, isn't there? For example, if we have docket ABC with two PDFs associated with it, then we get a doppeldocket in the same case, shouldn't we copy over the two PDFs to the doppeldocket?

@mlissner mlissner moved this to Backlog Jan 6 - Jan 17 in Sprint (Web Team) Dec 16, 2024
@albertisfu
Copy link
Contributor Author

Do you mean that initially we have, for example, a case with many entries and documents already merged into it, and at that moment, we don’t know it’s a doppel docket? Then, we get another docket that’s a subdocket of the initial cases so we need to merge the entries and PDFs from the initial docket into the new one?

If that’s correct, I have some questions:

Should we merge all the content from the initial case into all the other subdockets, or only certain entries/PDFs?
For instance, I recall recently reviewing this RECAP email while debugging a different issue:


Notice of Electronic Filing

The following transaction was entered on 12/9/2024 at 10:33 AM EST and filed on 12/9/2024
Case Name: In Re: Terrorist Attacks on September 11, 2001
Case Number: 1:03-md-01570-GBD-SN
Filer:
Document Number: No document attached
Docket Text:
***NOTICE TO COURT REGARDING PROPOSED DEFAULT JUDGMENT. Document No. (895 in 1:15-cv-09903-GBD-SN, 10586 in 1:03-md-01570-GBD-SN) Proposed Default Judgment, was reviewed and approved as to form. Filed In Associated Cases: 1:03-md-01570-GBD-SN, 1:15-cv-09903-GBD-SN(nd)

Case Name: Burnett et al v. The Islamic Republic of Iran et al
Case Number: 1:15-cv-09903-GBD-SN
Filer:
Document Number: No document attached
Docket Text:
***NOTICE TO COURT REGARDING PROPOSED DEFAULT JUDGMENT. Document No. (895 in 1:15-cv-09903-GBD-SN, 10586 in 1:03-md-01570-GBD-SN) Proposed Default Judgment, was reviewed and approved as to form. Filed In Associated Cases: 1:03-md-01570-GBD-SN, 1:15-cv-09903-GBD-SN(nd)


In this case, the entry appears to be shared between the two cases. I assume that shared entries make these two cases doppel dockets and related to each other. Here, it's a minute entry, but there should be other entries that contain PDFs.

However, I reviewed the first documents of each case, and they are different. This makes me wonder if this is a different type of doppeldocket where only a subset of entries is shared? If that’s correct, I don’t think it’s viable to copy all the content from one docket to another. Perhaps an additional step would be required to check which pacer_doc_ids are common between the two cases and copy only those PDFs. However, this approach will only work if the subdocket already has the entries and attachment data merged.

@mlissner
Copy link
Member

Yeah, that example is a bit strange, but even with that, I think the approach would be the same:

  • Do not copy over entries
  • Do copy over PDFs.

As you've observed, some of the entries will be shared, but not others. But the goal is to make each docket as complete as possible, which will mean copying PDFs bi-directionally.

@mlissner mlissner moved this from Backlog Jan 6 - Jan 17 to Backlog Dec 23 - Jan 3 Final (🌲) in Sprint (Web Team) Dec 20, 2024
@mlissner mlissner moved this from Backlog Dec 23 - Jan 10 (🎉) to To Do in Sprint (Web Team) Dec 23, 2024
@albertisfu albertisfu moved this from To Do to In progress in Sprint (Web Team) Dec 27, 2024
@albertisfu albertisfu linked a pull request Dec 30, 2024 that will close this issue
@albertisfu albertisfu moved this from In progress to In review in Sprint (Web Team) Dec 30, 2024
@github-project-automation github-project-automation bot moved this from In review to Done in Sprint (Web Team) Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants