Automatic Population of Permits

[0x4007]

• Using our metadata system we can easily GraphQL query for permits.
• import the "login with github" button from work.ubq.fi
• GraphQL query with authentication for private repos.
• limit to previous 100 results or whatever is the max that GraphQL can return in a single shot
• check if they have already been claimed, if so, discard
• if unclaimed permits are found, import into the UI (we should already support multiple permits to be loaded in the UI)

<!-- UbiquityOS - GithubCommentModule.transform - aaeed77eba29c75cd9fd4771a6a192acf88b4e32 - @gentlementlegen - https://github.com/Meniole/text-conversation-rewards/actions/runs/12626080982 
{
  "caller": "GithubCommentModule.transform"
}
-->

So now we should be able to go directly to pay.ubq.fi and it should automatically populate the permits.

If we pass in the permit directly (as we do normally) then it should just load the permit as it currently does.

The automatic population should add the permits to the queue after and only if logged in.

---

I reviewed the updated metadata and we should search for

<!-- UbiquityOS - GithubCommentModule.transform - 

[zugdev]

there is no upper bound to graphql query return count, its up to us to set that limit actually

[gentlementlegen]

The order got changed after you request:
ubiquity-os/plugin-sdk#46

There is a graphql limit to a 100 nodes, will crash beyond that (you need pagination). Also, sending more that a 100 nodes in a query also crashes the request.

[pbkompasz]

/start

[ubiquity-os]

! You must be a core team member, or an administrator to start this task

[ubiquity-os]

Important

• Be sure to link a pull-request before the first reminder to avoid disqualification.
• Reminders will be sent every 1 day and 18 hours if there is no activity.
• Assignees will be disqualified after 3 days and 12 hours of inactivity.

[ubiquity-os]

Passed the disqualification threshold and no activity is detected, removing assignees: @pbkompasz.

[zugdev]

/start

[ubiquity-os]

! You must be a core team member, or an administrator to start this task

[pbkompasz]

@zugdev I am already working on this and planned to open a PR today.

[zugdev]

You passed the threshold therefore I tried to start, it is generally a good idea to open a PR as soon as you start the issue. If you really do open the PR today, you can proceed, no worries!

[pbkompasz]

@zugdev I'll open a draft PR shortly.

You passed the threshold therefore I tried to start, it is generally a good idea to open a PR as soon as you start the issue. If you really do open the PR today, you can proceed, no worries!

When I applied initially the bot rejected the application and I only saw that I was manually assigned yesterday, but I am working on it.

[gentlementlegen]

The rejection is because this task is reserved to admins and collaborators which is why it closed the pull-request and did not assign you.

[Keyrxng]

I have a few points based on building the airdrop-cli

1. Issues can have multiple permits generated for the same person per issue. An early one may have been claimed, which should be verified before displaying anything.
2. The method for determining whether a permit has been claimed via permit2 will show true for a permit which was invalidated by the person who generated it. Which could make it difficult to determine whether a permit was actually claimed vs invalidated without confirming via on-chain transactions, I guess they scenarios require nuance in handling or a blanket approach.
3. Their may be multiple per issue with none claimed, and in such a scenario, do you take the most recent or the one of highest value?

[0x4007]

invalidated by the person who generated it

Doesn't matter much in this context. If its invalid due to the funder revoking it, or if it was already claimed- theres no point to display it on the claims UI because its unclaimable anyways.

or the one of highest value

I would take the one of highest value!

[Keyrxng]

I'd also suggest some kind of cache like a timestamp of the most recent permit generated at that point when searched so that upon return the next search begins from there vs trawling through all previous permits issues again.

A cache of unclaimed permits could exist where items are popped once they are claimed, to ensure historical permits prior to the search timestamp are not "forgotten".