Submitters aggregation for proceeding

[tangkun75]

For supporting flexible submitters aggregation for proceeding, e.g. the "Allowed Submitter" is (alice | bob) & (john , tom) which means to need approval from alice or bob and approval from john or tom to proceed. Below is the explanation about "Allowed Submitter":

User IDs and/or external group names of person or people permitted to respond to the input, e.g.:

"alice & bob" - means need both of alice and bob approve for proceeding
"alice | bob" - means need one of alice and bob approve for proceeding
"alice,bob" same as the above "alice | bob" for proceeding
"(alice | bob) & tom" - means need alice and tom approve or bob and tom approve for proceeding
So "&" means logical AND, "|" means logical OR, "," same as "|" and you can use "()" to group them.

[jglick]

I feel that this is getting much too specific. Better to ensure that the step includes very general features which can be used by script authors in various ways, including this one. For example, you can have a loop which collects approvals from different people, and then apply whatever logic you want to decide if the approvals suffice.

[tangkun75]

Thanks for your comments, @jglick
Yes, the current one is specific though I try to gain more general.
At the beginning, we wanted to try more flexible and complex logical decision based on submitters' approvals. And I notice that this plugin used 'submitter' for this decision logical elements and its logical decision implementation in 'input' step execution. So I tried one way: 'submitter' not only just logic elements, but also logic expression on itself (Groovy syntax is a good choice, that is why I made use of groovy to evaluate this logical expression in the end to avoid parse this expression by myself. But this way is still that both input (definition) and execution is on step level.
I just think that if moving the definition (submitters' approvals logic) out from "input" definition into the pipeline level (definition) as function or methods, and let step 'input' use/reference this function with step level's input (or interaction) for its internal submitters' decision flow dynamically. This way will supply script author more flexibility and more general and have all of benefits of pipeline script.
What's your opinion?

Thanks,

-Kun

[tangkun75]

@jglick , now I understand your points. I propose one way as below to do this. The advantages will be:

1. make input step execution implementation as simple
2. move the approvals evaluation into pipeline level, not step level.
3. let script author have more flexibility
4. more general to handle different scenarios.

---

def approvals = [:]
approvals['admin'] = false
approvals['qa'] = false
approvals['dev'] = false

def evaluateApprovals(approvals){
if(approvals['admin'] || approvals['qa']){
return true
}
return false
}

waitUntil{
def x = input message: 'Approve or not', submitter: 'admin,dev', submitterParameter: 'my-approval'
if(x != null){
approvals[x] = true
}
evaluateApprovals(approvals)
}