Skip to content

Feature: validator claim query#3

Merged
zacck-zz merged 24 commits into
masterfrom
feature/claim_query
Sep 25, 2019
Merged

Feature: validator claim query#3
zacck-zz merged 24 commits into
masterfrom
feature/claim_query

Conversation

@zacck-zz
Copy link
Copy Markdown
Contributor

@zacck-zz zacck-zz commented Sep 20, 2019

Changes Proposed

  • Collect all claims for a validator
  • Expose query to fetch claims
  • Ensure to collect only claims I can vote or I have voted on

@zacck-zz zacck-zz changed the title Feature: validator claim query [WIP] Feature: validator claim query Sep 20, 2019
@zacck-zz zacck-zz changed the title [WIP] Feature: validator claim query Feature: validator claim query Sep 23, 2019
Comment thread lib/bespiral/commune/commune.ex.orig Outdated
Comment thread priv/repo/migrations/20190920061915_verification_notification.exs
@zacck-zz zacck-zz requested a review from lucca65 September 23, 2019 14:48
Comment thread lib/bespiral/commune/commune.ex
Comment thread lib/bespiral_web/schema/commmune_types.ex Outdated
@zacck-zz zacck-zz added the 🧰 enhancement Changes and improvements to what we already have label Sep 24, 2019
Comment thread lib/bespiral_web/schema/commmune_types.ex Outdated
Comment thread priv/repo/migrations/20190923130436_verification_function.exs
@zacck-zz
Copy link
Copy Markdown
Contributor Author

@alissonfpmorais I think that should make it work, please see if it agrees with yours

@alissonfpmorais
Copy link
Copy Markdown
Contributor

@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 (symbol and logo related to each claim) and objective (id, also related to each claim). In that case the frontend will do multiples queries and then join all the results?
The same happens to verification screen, not only we need community and objective data, but, in case of multiples queries, we also need a way to get an specific entry of objective and claim.

Is this right? What you folks think about that?

@lucca65
Copy link
Copy Markdown
Member

lucca65 commented Sep 24, 2019

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

@zacck-zz
Copy link
Copy Markdown
Contributor Author

zacck-zz commented Sep 25, 2019

@alissonfpmorais @lucca65 with a couple of modifications to our Schema,

That is, adding the objective association to an action and community association to an objective we can pick this data entirely from the claims query as follows

query ($input: ClaimsInput!) {
  claims(input: $input) {
    id
    action {
      objective {
         id
        community {
          symbol
          logo
        }
      }
    }
  }
}

@alissonfpmorais
Copy link
Copy Markdown
Contributor

alissonfpmorais commented Sep 25, 2019

@alissonfpmorais @lucca65 with a couple of modifications to our Schema,

That is, adding the objective association to an action and community association to an objective we can pick this data entirely from the claims query as follows

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
  }
}

@zacck-zz
Copy link
Copy Markdown
Contributor Author

zacck-zz commented Sep 25, 2019

@alissonfpmorais I can do the query you need (claim(claim_input)) however I don't see the need to require the validator since the backend doesn't need to know about permissions really and the front end will have the validator id which it can tell from eos whether they can verify or not ... what do you think

@alissonfpmorais
Copy link
Copy Markdown
Contributor

@alissonfpmorais I can do the query you need (claim(claim_input)) however I don't see the need to require the validator since the backend doesn't need to know about permissions really and the front end will have the validator id which it can tell from eos whether they can verify or not ... what do you think

Yeah, since I've those data I can check it on frontend.
Makes sense! It's fine for me dude

@zacck-zz
Copy link
Copy Markdown
Contributor Author

@alissonfpmorais done 👍

@zacck-zz zacck-zz merged commit 1b346a6 into master Sep 25, 2019
@zacck-zz zacck-zz deleted the feature/claim_query branch September 25, 2019 14:31
lucca65 pushed a commit that referenced this pull request May 17, 2026
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🧰 enhancement Changes and improvements to what we already have

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants