Create a new API endpoint under the deposit service to get all organizations the user has deposited to.

• Write the new endpoint
• Write tests for the new endpoint

It should return a list like this:

{
  "depositOrgsForUser": [
    {
      "organizationId": "abc123",
      "organizationName": "Some org name",
    },
    {
       "organizationId": "def456",
       "organizationName": "Some other org name",
    }
  ]
}

We can put this new API under the organization service.

We need a new table for this data where each row is data shared by a user.
The primary key should be a composite key of the user pub key and the organization pub key (This is because only one share per user per organization to keep things simpler).

The API should take in the encrypted data and store it directly in the database.
The data is encrypted on the client side (in the app), so the API should be pretty simple.

Need a getter API as well for the organization to get the data for a user (and all data for a single organization).

Every API is currently just returning everything right now.

For every API that returns an "unbound" list of items, we need to:

1. Add pagination query params (similar to the ones used in the Cosmos SDK CLI client)
2. Set some sensible defaults (e.g. max 100 or 50 items per page by default or something like that)

• limit: pagination limit of all balances to query for (default 10)
• offset: pagination offset of all balances to query for
• page: pagination page of all balances to query for. This sets offset to a multiple of limit (default 1)

When claiming an RVM reward, there are no existing Deposit objects in the system. This is because the RVMs are considered offline and simply sign a message that the user will need to use in order to claim their reward.

For reference:

QR-Code Proposal:

• Format csv
  Header (1.Line)
• serial_no;receipt_id;timestamp;deposit
  Content (2. Zeile... – returned items)
• category_name;count;deposit
  Footer (last Line - Signature Validation)
• signature

Example:
90590043;121;2022-05-04T12:34:37+02;470
PET;20;15
CAN;17;10
4fab24da444bcc00756cc4209f428ce6

We need an admin-app to do certain things like creating schemes and stuff on behalf of our users. This app is only going to be used by us, so it doesn't need to look perfect or anything. It's a tool, and should not be spent more time on than necessary!

You can choose:

• Framework (Vue, React, etc)

• Design system/UI toolkit/Templates (find something nice and quick to use, we can pay for something too)

• Set up a webpage in a new folder called "admin-web" (MAKE SURE IT IS TYPESCRIPT)

• Login with Web3Auth

• Make a simple sidebar with the following pages: "Schemes", "Deposits", "Organizations", "Users"

This app is only going to be used by us, so it doesn't need to look perfect or anything. It's a tool, and should not be spent more time on than necessary!

• On the schemes page, show a table with all schemes.
• Button for "Create new Scheme" that opens a new page
• New Scheme page should have form fields for all the inputs used in the API

Currently, the scheme and deposit APIs only support the "weight" magnitude. Add support for the "Count" magnitude as well.

Epic for Voucher Reward API tasks

• #8

Create a new service to get user stats (i.e. new folder on the root of this project called "stats")

• Create the new service with the new API
• Write the tests

Return:

• Number of available (unused) vouchers
• Number of used vouchers
• Array of types of materials the user has deposited (aggregated)

Example:

{
  "numberOfAvailableVouchers": 3,
  "numberOfUsedVouchers": 42,
  "depositAmounts": [
    {
      "materialDefinition": {
        "plasticType": "PET"
      },
      "magnitude": 0, // 0 = Weight, 1 = Count. See commons/models.go
      "amount": 1.2
    },
    {
      "materialDefinition": {
        "plasticType": "HDPE"
      },
      "magnitude": 0, // 0 = Weight, 1 = Count. See commons/models.go
      "amount": 13.37
    },
    {
      "materialDefinition": {
        "plasticType": "Snus"
      },
      "magnitude": 1, // 0 = Weight, 1 = Count. See commons/models.go
      "amount": 314
    }
  ]
}

To see more details on the definition of the deposit amount model, look at https://github.com/empowerchain/deposit-backend/blob/main/commons/models.go

When you are done the file structure of the repo would probably look something like this:

- admin/ [+]
- commons/ [+]
- deposit/ [+]
- organization/ [+]
- scheme/ [+]
- stats/ [-]
  - stats.go
  - stats_test.go
- tmp/ [+]
...

The backend has the types for token, but it will not work now.
We need to add support in multiple APIs and extend tests:

• New Token definition API (similar to voucher definition but for a token)
• All the APIs that today deal with vouchers or voucher definitions today (most of scheme and deposit services)

Epic for Deposit API

• #9