A web-app intended to be used by canvassers campaigning for a 'Yes' vote in the second independence referendum. The web-app will be delivered to canvassers out knocking doors primarily through an HTML5/React single-page app designed to work on a mobile phone; it's possible that someone else may do an Android of iPhone native app to address the same back end but at present I have no plans for this. There must also be an administrative interface through which privileged users can set the system up and authorise canvassers, and a 'followup' interface through which issue-expert specialist canvassers can address particular electors' queries. See https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/488478/Bulk_Data_Transfer_-_additional_validation_valid_from_12_November_2015.pdf, section 3 A valid postcode. All users All users of the canvasser app Able to read and add canvassing data in a limited radius around their current position. Organisers of canvassing teams Able to see and modify data on the canvassers in the team(s) they organise; able to add canvassers to their team; able to update canvassers in their team, including resetting passwords and locking accounts; able to see canvass data over the whole area in which their team operates. People expert on particular issues. Able to read followup requests, and the electors to which they relate; able to access (read/write) the issues wiki; able to write followup action records. Users entitled to see an overview of the canvassing data collected. Able to read canvassing data over the whole map, including historical data. Users responsible for determining what issues should be current at any time. Able to set current issues; able to add issues. Able to read and update canvasser records, team membership records, team organisership records, issue expertise records; able to add and update reference data generally. All electors known to the system; electors are people believed to be entitled to vote in the current campaign. The signature of this elector, captured as SVG text, as evidence they have consented to us holding data on them. Null if they have not. All genders which may be assigned to electors. All dwellings within addresses in the system; a dwelling is a house, flat or appartment in which electors live. Every address should have at least one dwelling; essentially, an address maps onto a street door and dwellings map onto what's behind that door. So a tenement or a block of flats would be one address with many dwellings. The part of the address which identifies the flat or apartment within the building, if in a multiple occupancy building. Addresses of all buildings which contain dwellings. Locality indexing; see issue #44. Note that this property should be generated automatically from the latitude and longitude: (+ (* 10000 ;; left-shift the latitude component four digits (integer (* latitude 1000))) (- ;; invert the sign of the longitude component, since ;; we're interested in localities West of Greenwich. (integer (* longitude 1000)))) We'll use a trigger to insert this. I don't think it will ever appear in the user interface; it's an implementation detail, not of interest to users. All visits made by canvassers to dwellings in which opinions were recorded. But only in their immediate area. Authorities which may authenticate canvassers to the system. Issues believed to be of interest to electors, about which they may have questions. Intentions of electors to vote for options elicited in visits. The locality at which the intention was recorded; used where an elector does not consent to have polling intention stored against them. This is a locality as described in The locality at which the intention was recorded; used where an elector does not consent to have polling intention stored against them. This is a locality as described in Primary users of the system: those actually interviewing electors. An image of the canvasser, so that other members of their team can recognise them. Information the canvasser supplies about themselves; an introduction. Only relevant to issue experts. Teams this canvasser is a member of. But only their own record But only canvassers in their own team. All canvassers Requests for a followup with an issue expert Phone number or email address for followup. The issue expert who is currently handling this issue, if any. A role (essentially, the same as a group, but application layer rather than database layer) of which a user may be a member. But only their own group(s) All groups An event to which a team or teams are invited. Typically created by the team organiser(s). May be a training event, a social event or a canvassing session. Actions taken on followup requests. But only for electors in their immediate vicinity Options in the election or referendum being canvassed on Methods which may be used to follow up a followup request. Reference data.