# Voting happ

> Note: this is a very minimal design for an application. Usually you'll need more DNA/zomes and complexity to cover all that you need to cover your use case

[TOC]

# Requirements
Use case: A local community group (e.g. neighborhood association, local cooperative, etc.) needs to pass a couple resolutions and have a clear tally of votes by the end of the week. All members of the app are all able to vote so you’ll want to restrict membership to community members.

Scale: less than 500 people
Time: Deadline vote by end of week
Secrecy: Vote content does not need to be hidden

# DNAs

## Voting DNA

- Membrane: closed membrane, members can join only (vetted by 1 other member).

### Posts zome
Simple Diagram:

digraph g {

node [
fontsize = "16"
shape = "record"
];
// Maybe this with timestamp mods?



"resolution" [label="{Resolution | { description | author | endtime | timestamp  }}"]
"vote" [label="{Vote | { Yes/No | timestamp  }}"]
"member" [label="{Member | { name | timestamp  }}"]
"member"->"member" [label="vetted"]
"member"->"vote" [label=""]
"vote"->"resolution" [label=""]
"member"->"resolution" [label="propose"]
}

Entry Relationship Diagram Example:

digraph g {

node [
fontsize = "16"
shape = "record"
];
// Maybe this with timestamp mods?



"resolution" [label="{Resolution | { description | author | endtime | timestamp  }}"]
"resolution2" [label="{Resolution 2 | { description | author | endtime | timestamp  }}"]
"vote" [label="{Vote | { Yes/No | timestamp  }}"]
"vote2" [label="{Vote | { Yes/No | timestamp  }}"]
"vote3" [label="{Vote | { Yes/No | timestamp  }}"]
"vote4" [label="{Vote | { Yes/No | timestamp  }}"]
"vote5" [label="{Vote | { Yes/No | timestamp  }}"]
"vote6" [label="{Vote | { Yes/No | timestamp  }}"]
"member" [label="{Original Member | { name | timestamp  }}"]
"member2" [label="{Member 2 | { name | timestamp  }}"]
"member3" [label="{Member 3 | { name | timestamp  }}"]
"member"->"member2" [label="vetted"]
"member2"->"member3" [label="vetted"]
"member"->"vote" [label=""]
"vote"->"resolution" [label=""]
"member2"->"vote2" [label=""]
"vote2"->"resolution" [label=""]
"member3"->"vote3" [label=""]
"vote3"->"resolution" [label=""]
"member"->"vote4" [label=""]
"vote4"->"resolution2" [label=""]
"member2"->"vote5" [label=""]
"vote5"->"resolution2" [label=""]
"member3"->"vote6" [label=""]
"vote6"->"resolution2" [label=""]
"member"->"resolution" [label="propose"]
"member2"->"resolution2" [label="propose"]
}

When querying by time, you can first get all the paths that are

#### Validation

Entries

* `resolution`:
* Create:
* Check that the member is vetted by at least one other member
* Update or Delete:
* Check that the author of the update or delete element matches the author of the original element.

* `vote`:
* Create:
* Check that the member is vetted by at least one other member & that only one vote for this resolution has been made by this member and it is before final time
* Update or Delete:
* Check that the author of the update or delete element matches the author of the original element.

Links?
* `path->vote->resolution`:
* CreateLink and DeleteLink:
* Get target resolution of link
* Check that post.author matches link.author

#### Signals
- Every time someone creates resolution, the UI will receive a signal:
- Every time someone votes, the UI will receive a signal:

{
  "post_hash": <POST_HASH>,
  "agent_pub_key": <AGENT_PUB_KEY>,
  "action": "LIKE"
}