Define the structure of ipfs data for approved/rejected grant applications

[chibie]

context:

When the operators visits the review page, they would be able to see all the applications indexed by the graph, all in pending review state.

The operator would now be able to approve / reject the applications. Once the decision has been made.
The round manager saves this information to IPFS and invokes updateProjectsMetaPtr with the IPFS hash
which:

• updates the projectsMetaPtr
• fires the ProjectsMetaPtrUpdated event

This projectsMetaPtr contains a list of all projects which have either been rejected or approved.
Pending projects not be included here

// TODO : decide structure of projectsMetaPtr content

[chibie]

based on the current subgraph implementation, i suggest this structure as a quickie to be improved upon if anything changes

[
  {
    id: string,
    status: "APPROVED" | "REJECTED",
    payoutAddress: string
  },
  ...
]

[thelostone-mc]

Yup this should work for now 🙌🏼

[nfrgosselin]

@chibie do we need an explicit status for pending? If not, what would be in the field when an application has been received but not approved/rejected yet?

[chibie]

@nfrgosselin only approved or rejected grants will be on ipfs... pending applications are tracked via indexed contract events on the subgraph