Feature: validator claim query#3
Conversation
- Manipulate state to build realistic data for claims
933d401 to
22300cc
Compare
and the query will also return an empty list
|
@alissonfpmorais I think that should make it work, please see if it agrees with yours |
Hey @zacck I've tested and now looks like that the query return the correct claim, but before merge it, I would like to know from you @zacck and @lucca65 how we gonna use those queries. The dashboard also needs data related to community ( Is this right? What you folks think about that? |
|
yeah this is a possibility, but we can also query several different queries on GraphQL, no need to actually do different queries, for example: query {
x: community(symbol:"BES") {
description
}
y: community(symbol:"LOR") {
description
}
}
Maybe to improve this conversation, can you please send me the graphql query to the claims, and we can create a new one that contemplates the community queries as well so you get descriptions, logo and symbols to your heart's contents |
|
@alissonfpmorais @lucca65 with a couple of modifications to our Schema, That is, adding the query ($input: ClaimsInput!) {
claims(input: $input) {
id
action {
objective {
id
community {
symbol
logo
}
}
}
}
} |
@zacck Really cool dude, like it a lot!! One more thing is that we also need a way to get a specific verification for the verification screen. Maybe something like? query($input: ClaimInput!) { // with ClaimInput being claim ID and the validator who is requiring the claim (so you can check if that validator can verify that claim or not)
claim(input: $input) {
// data needed
}
} |
|
@alissonfpmorais I can do the query you need |
Yeah, since I've those data I can check it on frontend. |
|
@alissonfpmorais done 👍 |
* Test that we can collect a validators claims * Debug verification notifications * Expose validator claims query * Update deps for needed works * Update action factory and add check factory * Annotate tests with comments for logic - Manipulate state to build realistic data for claims * Update action fields * Split claims query into two parts so as to collect available and voted for queries * Remove debugging * Separate trigger and functionfor claims * Version bump for feature * Remove merge marker * Make validator non_null * Change criteria set to include more complex actions * Select claims better and annotate query * Make list of claims non_null to avoid Maybe and the query will also return an empty list * Clean up db state before migrating new function * Ensure list of claims is uniq since the available logic can pick a claim twice * Update database state in test for testing; * Correct short hard code * Adjust logic to pick up correct verifications * Update objective and action schemas with associations * Add integration test for resolver function to fetch claim * Implement single claim query
Changes Proposed