# DLT4EU keeping track of stuff

### Todo last days (or a record for later on low priority items)

2. Looks like the vc validations have moved to the vc creation, nice! Might be good to remove from the donation page, so it gets better performance. (medium)
3. Transaction list should sort descending by date.
4. When creating a donation with no quality rating, it gives an error message, but does create it. It should just create it, that is valid. (low)

| piece | is it in? | status |
| ---- | ----- | ---- |
| ValueCalculation CRUD & graphql | yes | Done |
| ValueCalculation federation | yes, low priority | |
| Calculate reciprocal value from donation event | yes | Done - testing |
| Create reward event and agreement from calculation | yes | Done |
| Agreement CRUD & graphql | yes | Using EconomicEvent.triggeredBy |
| Observe/Measurement CRUD and graphql | yes | Done |
| Observe/Measurement federation | yes, low priority | |
| Make feature configurable | probably not | |
| Connect with buzzoek or similar | don't know | |
| UI for registering agents, users | maybe, low priority | Prototype |
| UI for ValueCalculation CRUD | yes, low priority | Including also resource specifications and observable phenomena |
| UI for map of drop off sites | yes | | Prototype done, to be adapted
| UI for entering donation EconomicEvent | yes | WIP |
| UI for calculating and saving reciprocal EconomicEvents | yes | WIP |
| UI for the citizen donor (stamps?) | time dependent | |
| UI for the local business (stamp redemption) | probably not | |
| Feature testing | yes | WIP |
| Set up installation for users | don't know | |

Reasonable order of development to deliver by priority.

**1. Citizen donates some textiles at a drop-off site, system calculates and saves rewards. All in the drop off site user app.**
* Enter donation event
* need existing code moved over for EconomicEvent, EconomicResource, Action, ResourceSpecification) Done.
* we'd have to put some resource specs in with graphiql, also a generic agent perhaps for donors (?), and agents for orgs, administrators, drop off sites, and drop off site people
* enter donor event info, including quantity:
* resourceConformsTo (user selection)
* resourceQuantity (unit from the resourceSpecification)
* action: transfer
* provider: the generic citizen agent???
* receiver: the agent for the drop off site
* hasPointInTime: system time
* inScopeOf: ?? (Lynn think about, and/or let's discuss)
* create a resource (resourceInventoriedAs)
* enter one or more observations (new measurement model) (figure out if this should be configured in some way - how does it know? Lynn tbd.)
* Based on donation event, system calculates the quantity for the reward event
* value calculation data needs to exist already, we could just get it in with graphiql
* Create the new event,
* and create an Agreement with the donation and reward events attached to it (realizationOf)
* event data:
* action: from the value calculation value action
* provider: the agent for the drop off site???
* receiver: the generic citizen agent???
* hasPointInTime: system time
* resourceConformsTo: the token (hard code in the UI?)
* resourceQuantity (from the calculation, unit from the value calculation)
* inScopeOf: ??
* Display all this back to the site person.

**2. Agent/user registration. (done by administrator?)**
* CRUD page for creating organizations, with their primary location
* Registration for users, maybe relationship to their org (?)

**3. Citizen gets and keeps record of rewards.**
* This is a separate app (browser based) on the citizen's phone to receive tokens.
* We are still investigating if we can use an existing service to do this with a stamping or scanning to give the citizen the record of their tokens.

**4. Citizen looks online at map of drop off sites.**
* Map of drop off sites (agents) with location info.

**5 Add the CO2/etc. savings to the results.**
* Create a display of the CO2 savings, calculated using the textile weight. This happens at the same time the tokens are recorde on the citizen's app. It can be hard-coded.

**6. Administrator maintains resource specification information.**
* List and CRUD for resource specifications.

**7. Administrator maintains value calculation information.**
* List and CRUD for value calculations.

**8. Administrator maintains observation phenomena information.**
* List and CRUD for ObservableProperty and ObservablePhenomenon.