Handle private bills during event packet build

[hancush]

Overview

Sometimes event agenda items can be associated with matters that are private (or otherwise do not meet criteria for display on the board agendas site). When this happens, it causes event packet building to fail! See: Metro-Records/la-metro-dashboard#46. This PR handles that exception.

Checklist

• PR has a descriptive enough title to be useful in changelogs

Notes

We run the risk of this happening everywhere we access bills via a foreign key relationship that has been overridden to use LAMetroBill. (IIRC, there are 3-4 places, including this one.) I'll open a separate issue to audit that, since this patch is time sensitive.

FWIW, I don't see a solution to handle this further upstream, e.g., in django-proxy-overrides, though I'd be happy to discuss, if one seems obvious to you, @fgregg!

Testing Instructions

• Merge this PR, and wait for the latest staging tag to build in Dockerhub.
• Trigger the hourly_processing DAG on the dashboard and confirm the compile_pdfs task succeeds.

Handles Metro-Records/la-metro-dashboard#46

[fgregg]

if we are going to scrape private & test bills, then this solution makes sense.

iirc, the reason that we scrape private bills is so that sometimes a bill was public and we need to make it private so we need it to update that status.

that makes me think about addressing the deletion problem: opencivicdata/pupa#295

if that was addressed, then we could not scrape private bills and get the behavior we want.

we might still need the code you are writing here, because we would have test bills which we also no not want to show.

these are just general remarks. resolve my Q on your comment, and I'll be good to approve.

[fgregg]

could this also happen for test bills?

[hancush]

Good catch – yes! It can happen if the bill does not meet the criteria for display, only one of which is because it's private:

https://github.com/datamade/la-metro-councilmatic/blob/763d58553f4dd2d2041d8abd6e9e12a6fa25346d/lametro/models.py#L51-L58

I'll clarify this comment.