ciudadanointeligente / write-it / 2876
98%
master: 98%

LAST BUILD BRANCH: alpaca-rebased-django-1.8
DEFAULT BRANCH: master
Ran
Jobs 2
Files 113
Run time 48s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
2876

push

travis-ci

mhl 
If we can tell which people are current, only include them

Since the migration to syncing people using django-popolo and
multiple-django-popolo-sources, we're now syncing all people (even
historic representatives) from EveryPolitician, not just those in the
current term(s).  However, we should only be allowing people to write
to current representatives.

The problem here is that the old behaviour was just to include everyone
from the data source who had a contact and hadn't been deliberately
disabled - some (or perhaps most) of these non-EveryPolitician data
sources won't have any way to tell who is current or not; the assumption
should continue that they should all be made available to write to.

We could divide these cases into sources that look like they're from
EveryPolitician or not from the URL, but that wouldn't help with people
serving EP data from elsewhere, or after modification.  Probably the
best approach would be to only show current representatives for sources
that have Event objects with classification "legislative period", and
then decide who is current by looking at those who have memberships with
a legislative_period_id corresponding to a current legislative period.

Unfortunately, at the moment django-popolo does not include the Event
class, and we need a workaround quickly for the Alpaca project, so this
commit uses a different heuristic for when to attempt to filter people
for being current memberships of a legislature: if the people from that
source have any memberships at all, it only includes those people who
have a current membership (of any organisation - of course this might
be completely spurious). This is good enough for the Alpaca case, which
will give us enough time to update django-popolo and
multiple-django-popolo-sources so that we can do this properly for the
main production writeinpublic site.

This commit also doesn't address whether historic representatives are
available via the API.

8439 of 8597 relevant lines covered (98.16%)

1.96 hits per line

Jobs
ID Job ID Ran Files Coverage
1 2876.1 (DB=postgres) 0
98.16
 Travis Job 2876.1
2 2876.2 (DB=sqlite3) 0
98.16
 Travis Job 2876.2
Source Files on build 2876
Detailed source file information is not available for this build.