Open gordonje opened 6 years ago
1 (and also 2, I guess): So Organization
is in the core
module and defined generically, but it's non-abstract? I'm far out of my depth re: Popolo and OCD classifications, but those seem like reasons it'd be a fair candidate for subclassing.
3: Yes, for sure. Though, since it's not always clear from a disclosure whether a donor is a person, company or even committee, would it be better to have a generic donor
entity with flags for person
, committee
or organization
? Not sure how to distinguish between the latter two; companies are clearly organizations and not committees; on the other hand, the entity doing the donating on behalf of a company is often a committee set up by that company. Some disclosures in some jurisdictions, filed by some campaigns, make it (reasonably) clear which is which, but many do not.
4: Yeah, there can be fairly intricate relationships between different types of committees and organizations. In WA, the state D and R parties have specific committees who fundraise and make donations to candidates in each chamber of the legislature (Kennedy Fund, Truman Fund, etc). Those committees are essentially controlled by the state parties, but nominally different entities.
I'm working on filling out @aepton's implementation of the Campaign Finance enhancement proposal, and I've uncovered an issue @jamesturk might need to consider sooner rather than later.
In the campaign finance OCDEP,
Committee
is described as a "Subclass of Popolo Organization", and adds a couple of attributes not expected on the base class. The existing OCDOrganization
class is a non-abstract model, and my understanding is that, as a general rule, we don't want to subclass non-abstract models.This is similar to the
Event
/Election
situation we got into previously. The solution then was to partially copy the definition of theEvent
model and create a newElection
model. We also copied the definitions of theEventIdentifier
andEventSource
models to make newElectionIdentifier
andElectionSource
models.I'm following this same approach for
Committee
and it's related models, but a few things give me pause:Event
was in thelegislative
module and was tailored to those use cases,Organization
is in thecore
module and is defined rather generically.Organization
has a couple of other related model thatCommittee
also needs:OrganizationIdentifier
for storing alternate ids for the campaign finance committeeOrganizationName
for storing the committee's various different namesMembership
andPost
for storing relationships committees and their treasurers, officers, staff, etc.OrganizationSource
andOrganizationContactDetails
Transaction
has a.sender
and.recipient
each of which will have either a.person
or.organization
attribute populated, depending on the entity type. Under the current pattern, I think we also need a.committee
attribute, since these can also send and receive transactions.If 4 is a real need, then it feels like exactly what Django's multi-table inheritance was designed for. Even if it isn't, multi-table inheritance would also address the issues raised in 2 and 3.