PortalaAdapter: client-side Antrag-Filter immer aktiv (#61 Bug 5)

BE-Adapter hat document_type=None (eigene ETYPF-Werte werden vom
Berliner PARDOK nicht akzeptiert), wodurch der Server alle Doku-Typen
zurückliefert. Das 200-Result-Window war damit vollständig von
'Schriftliche Anfrage'-Hits aushungernd, sodass Anträge wie 19/2650 nie
ans Frontend kamen — und get_document() für genau diese Drucksachen
None lieferte.

Patch: client-side 'antrag'-Substring-Filter läuft jetzt unabhängig
vom Server-Filter (vorher nur wenn document_type gesetzt war). BB/RP
und alle PortalaAdapter-Instanzen profitieren mit.

176 Unit-Tests grün, Live-Verifikation Sub-B im Container nach Deploy.

Refs: #61 Bug 5

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dotty Dotter 2026-04-09 12:11:20 +02:00
parent a3a9052dec
commit 060a33ea5f

View File

@ -772,14 +772,15 @@ class PortalaAdapter(ParlamentAdapter):
results = self._parse_hit_list_html(report_resp.text, query_filter=query)
# Server-side ETYPF/DTYPF filter is best-effort across portala
# instances — BB/RP let "Kleine Anfrage" und "Beschluss-
# empfehlung" durch (siehe #61 Bug 2/3). Client-side strict
# filter on the parsed typ-string. Whitelist via Substring,
# damit "Antrag gemäß § 79 GO" und ähnliche Subtypen passieren.
if self.document_type:
target = self.document_type.lower()
# empfehlung" durch, BE hat sogar `document_type=None`
# (eigene ETYPF-Werte), wodurch "Schriftliche Anfrage" das
# 200-Result-Window aushungern und Anträge wie 19/2650 nie
# zurückkommen. Wir filtern client-side IMMER auf
# "antrag"-Substring im typ — unabhängig davon, ob der
# Server-Filter gesetzt war (siehe #61 Bug 2, 3, 5).
results = [
d for d in results
if target in (d.typ or "").lower()
if "antrag" in (d.typ or "").lower()
]
return results[:limit]