MultiBounties: Fund panel update

[rkzel]

So number of bounties per issue can be configured:

[rkzel]

Frontend changes are not a problem, but backend... there is 1:1 Issue-Bounty relationship created by Issue struct:

struct Issue {
   (...)
   uint standardBountyId;
   address assignee;
   (...)
}

Two fields especially: one ID of singular standard bounty, and assignee field, also singular, containing address of the person who requested assignment and got approved. Assignee field also helps with marking bounties as "open submission" vs "applications required".

What is needed for multibounties is to be able to assign multiple standard bounties to one Issue.

There are two possible contract-level solutions:

1. Create multiple Issues in addBounties and AddBountyNoAssignment (directly below AddBounties) functions - which might be easier to deal with, but will require more space for redundant data in the contract,
2. Change Issue struct so that assignee and standardBountyId are arrays. Then one Issue could hold a number of standard bounty ids created by addBounties calling _issueBounty in a loop.

In both cases changes to functions managing bounties (like requestAssignment, reviewApplication, etc) will be needed.

For now I'll get frontend to understand multiplicity as much as is required by design and allowed by the lack of presence of the underlying functionality...

RFC: @topocount @ottodevs @Quazia

[topocount]

@rkzel We can work around the require without making contract changes: https://github.com/AutarkLabs/open-enterprise/blob/7ad39556880f1daee36d910bed7bda1980d87360/apps/projects/contracts/Projects.sol#L934

The way we should do it is by making "shadow" issues that contain the key back to the first "real" issue. The link to the real issue can be stored in the IPFS blob, and then the issue can be conjoined with the parent issue (the first bounty logged against that github issue) in the frontend in script.js. I recommend making "shadow" issues by incrementing the most x significant bits of the uint256 representating the issue. The best way to design this numbering system is to set a cap on the number of bounties an issue can have, and then increment each successive most significant bit to each nth shadow issue, where n is the number of bounties stored on the issue. This way you can add multiple bounties to a single tx in deterministic way. In short, we can take the x most significant bits (depending on our cap of bounties per issue)and use those to track shadow issues, basically storing two values in each uint256. where the first x bits track the number of shadow issues and the remaining 256-x bits store the real parent issue number.

The other option is obviously updating the contract, which is probably a better long-term solution but might be difficult to get out on mainnet anytime soon.

[stellarmagnet]

@topocount so this would be the non-native SB way of doing it?

What if the user wants to cancel the bounty? It cancels all of them?

[topocount]

so this would be the non-native SB way of doing it?

There is no way in the standard bounties integration we have (and probably the contract unless major changes have been made in the last couple months) to allow for multiple token awards against a single bounty. We'll have to create a new bounty for each token regardless.

What if the user wants to cancel the bounty? It cancels all of them?

We have a multi-bounty removal function so it'll work the same way as adding them: https://github.com/AutarkLabs/open-enterprise/blob/7ad39556880f1daee36d910bed7bda1980d87360/apps/projects/contracts/Projects.sol#L567-L579