Rechargeable Token payment Contract

[ipapandinas]

No description provided.

[ipapandinas]

In relation to @leapalazzolo 's ideas here: kudos-ink/incentive-demo#1 (comment)

@ipapandinas , What do you think about this new trait and storage?

• set_reward to send extra rewards to unclaimed issues
• new type called ContributionId to allow issues from different repositories of the same organization in the contract
• a registration_payment to be sent by the contributor when registering in the contract.

ContributionId

pub struct ContributionId {
    // The unique repository ID (e.g. the Github Repository id).
    repository_id: RepositoryId,
    // The unique contribution ID (e.g. the Github issue #id).
    id: IssueId,
}

Trait

#[openbrush::trait_definition]
pub trait Workflow: Ownable {
    /// Register the caller as an aspiring contributor.
    #[ink(message)]
    fn register_identity(&mut self, contributor_id: String) -> Result<(), WorkflowError>;

    /// Approve contribution. This is triggered by a workflow run.
    #[ink(message)]
    #[modifiers(only_owner)]
    fn approve(
        &mut self,
        contribution_id: ContributionId,
        contributor_id: String,
    ) -> Result<(), WorkflowError>;

    /// Check if the caller is the contributor of a given `contribution_id`.
    #[ink(message)]
    fn check(&self, contribution_id: ContributionId) -> Result<bool, WorkflowError>;

    /// Check the ability to claim for a given `contribution_id`.
    #[ink(message)]
    fn can_claim(&self, contribution_id: ContributionId) -> Result<(), WorkflowError>;

    /// Claim reward for a given `contribution_id`.
    #[ink(message)]
    fn claim(&mut self, contribution_id: ContributionId) -> Result<(), WorkflowError>;

    /// Set an extra reward for unclaimed contributions
    #[ink(message, payable)]
    fn set_reward(&mut self, contribution_id: ContributionId) -> Result<(), WorkflowError>;
}

Storage

    pub struct SingleToken {
        #[storage_field]
        ownable: ownable::Data,

        // The default contribution reward amount.
        reward: Balance,

        // The amount required for users to become contributors
        registration_payment: Balance,

        // A collection of extra rewards to encourage contributors to take specific issues
        donations: Mapping<ContributionId, Balance>,

        // The approved contributions ids database.
        // The key refers to a registered and unique contribution.
        // The value is the associated information of the contribution.
        contributions: Mapping<ContributionId, Contribution>,

        // The registered contributors ids database.
        // The key refers to a registered and unique contributor ID (e.g. the Github user).
        // The value is the associated registered `AccountId` (public key) of the contributor.
        identities: Mapping<String, AccountId>,
    }

I like the ContributionId type. Do you imagine RepositoryId & IssueId as type aliases for ink::prelude::string::String & u64?

What is the need of have both reward and donations in the contract storage? I don't quite understand the difference.

[leapalazzolo]

1. Yes

pub type RepositoryId = u64;
pub type ContributorId = String;

2. We might need to reconsider the implementation. Currently, a new contribution is added to contributions when it's approved (i.e., the issue is closed). Consequently, it doesn't exist in the contract before it's completed by the contributor, making it impossible to donate beforehand because it doesn't exist. Using separate mappings would enable us to donate money before or during someone working on the issue, and when it's approved, we can check previous donations.

On the other hand, reward represents the default reward for all issues (base reward). However, I don't find this approach realistic. It might be worth considering adding the issues to the contract when they are created with a custom reward (which could even be renegotiated within the issue).