Viewable reports #357
Viewable reports #357
Conversation
…related field in the Solr schema
There was a problem hiding this comment.
i left a couple of comments inline! one more: if we ever access bills in the ui like lametrobill.objects.all(), it may be a good idea to implement a manager that only returns the viewable bills. i did a similar thing for test events, if we go that route:
then,
| return True | ||
|
|
||
| events_with_bill = Event.objects.filter(agenda_items__bill_id=self.ocd_id) | ||
| passed_events = [event for event in events_with_bill if (event.status == 'passed' or event.status == 'cancelled')] |
There was a problem hiding this comment.
will this array ever become very large? since we only care about the presence, but not how many, etc., it may be more memory-efficient to do something like:
for event in events_with_bill:
if event.status in ('passed', 'cancelled'):
return True
return FalseThere was a problem hiding this comment.
No, this list will never be very large – a bill may be associated with one or two events. More than that does not align with what Metro has done historically.
| @@ -739,6 +739,8 @@ def search(self): | |||
| # Don't auto-escape my query! https://django-haystack.readthedocs.io/en/v2.4.1/searchqueryset_api.html#SearchQuerySet.filter | |||
| sqs = sqs.filter_or(attachment_text=Raw(self.cleaned_data['q'])) | |||
|
|
|||
| sqs = sqs.filter(viewable=True) | |||
There was a problem hiding this comment.
if we always hide bills, should we index them at all?
There was a problem hiding this comment.
(i.e., do we have all the info we need to omit them when we build the index?)
There was a problem hiding this comment.
(i forget, does our current pipeline update the index with every scrape, or with enough frequency for this suggestion to make sense?)
There was a problem hiding this comment.
I asked myself this very question!
I decided to index "hidden" bills for one reason – the integrity script, which checks that the Councilmatic database and the Solr index have the same number of bills. If we do not index a "hidden" bill, then this script will complain. I think it's easier to modify the SearchQuerySet, rather than find a workaround with how the integrity script or import_data works.
(N.B. data_integrity runs after every execution of update_index, which runs after import_data which runs four times per hour.)
There was a problem hiding this comment.
ha, great minds. :-) that makes sense to me. maybe it would be good a drop a comment or docstring in the search_indexes.py file?
|
Ah, that I thought about all the places where we render bills, and the only instance where we render all bills is on the search view (which uses the sqs object). For other places, we show bills based on whether or not they have actions (i.e., the person detail) or appear on an agenda (i.e., the event detail). I do think I need to account for the later case. |
|
@reginafcompton i think that that sounds right, but that a manager may still be a good idea, unless there will ever be a case where we want to show non-viewable bills. |
|
@hancush, if we add a context manager, as you've done with the Event, then we'd end up adding the bills to the Solr index (which is not desirable, c.f. above). I suspect there might be a way to build an LAMetro bill manager, so that Haystack ignores it. But, again, I cannot think of a use case in which we risk showing "hidden" bills (other than the search page)...so, again, I am wondering if we need the manager at all. Do you want to chat about this further? |
This PR handles the last portion of issue #345