Hey Coin,
I totally understand the problem and I agree that we can craft a better solution. The curators I interact with normally react fast enough to have averted this issue. If we are caught we don’t have to manually setup the extrinsic all over again, we just run a script and the id’s are updated within a new call-data hash. All descriptions, fees, recipients are held in separate storage items.
If I had to ponder a solution I would suggest something like the below. Please try to grasp the concept and appreciate that I am not a frame developer. I could probably hack away to get it functional but this is just a forum discussion.
//Type to define bounty line items
pub type bounty_line_item{
child_curator:AccountID, //Child curator address
fee: BalanceOf<T>, //Curator fee
value: BalanceOf<T>, //Value to disburse
description: Vec<u8>, //Description for child bounty
beneficiary: Option<AccountIdLookupOf<T>> //Account receiving funds
}
//Decorator to ensure that all entries are executed in an atomic manner
/*
Single extrinsic to award a child bounty and propose a child curator.
If the submitter is the child curator then accept the child curator position
and attempt to award to the beneficiary
*/
pub fn disburse_bounty(
origin:OriginFor<T>,//curator
parent_bounty_id: BountyIndex,
bounty_entries: Vec<bounty_item> //An array of items conforming to the type above
) -> DispatchResult{
/*
Do verification stuff here like ensure the bounty exists,
that it has funds and that the origin is the curator of this bounty
etc.
*/
for bounty_item in bounty_entries.iter() {
add_child_bounty(...);
//get child bounty index and use in the following
propose_curator(...);
if(bounty_item.child_curator == Origin){
accept_curator(...);
award_child_bounty(...);
}
}
}