The Promotions are configured with these upstream criterias:
A: manual
B: manual, when A is promoted
C: manual, when B is promoted
1.User Approves promotion A
2.User Clicks on the approve button of Promotion C.
3.User Approves promotion A
On following the above steps promotion C is getting auto promoted after Promotion B is approved.
First of all the approve buttons of downstream promotions should be disabled if one upstream promotion has not happened and downstream promotion has dependency on it.
I do not understand the reproduction steps. there is no "Approve B" in these steps, so I am not sure what you actually do
Oleg Nenashev
added a comment - I do not understand the reproduction steps. there is no "Approve B" in these steps, so I am not sure what you actually do
2.Then Approve C(No action ll be carried out as promotion B is pending)
3.Approve B
Then check Promtion C..it will be re executed by SYSTEM.
But ideally it should not be re executed by SYSTEM.
Saga P
added a comment - - edited 1.Approve A
2.Then Approve C(No action ll be carried out as promotion B is pending)
3.Approve B
Then check Promtion C..it will be re executed by SYSTEM.
But ideally it should not be re executed by SYSTEM.
Sorry, over last months I had no time to work on the plugin, because I had to focus on the Jenkins core and other projects. I also have not been using this plugin on my own since 2016. So I have decided to unassign the issues so that there is no expectation that I work on them anytime soon.
Currently the plugin is being transfered to another maintainer. Hopefully he will have some time to finish triaging of the issues and maybe to deliver some fixes. But, as in any community-driven project, everybody is welcome to propose pull requests and to contribute to the plugin's state.
Oleg Nenashev
added a comment - Sorry, over last months I had no time to work on the plugin, because I had to focus on the Jenkins core and other projects. I also have not been using this plugin on my own since 2016. So I have decided to unassign the issues so that there is no expectation that I work on them anytime soon.
Currently the plugin is being transfered to another maintainer. Hopefully he will have some time to finish triaging of the issues and maybe to deliver some fixes. But, as in any community-driven project, everybody is welcome to propose pull requests and to contribute to the plugin's state.
Unassigned
Saga P
Votes:
0Vote for this issue
Watchers:
2Start watching this issue
Created:
Updated:
{"errorMessages":["jqlTooComplex"],"errors":{}}
[{"id":-1,"name":"My open issues","jql":"assignee = currentUser() AND resolution = Unresolved order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-2,"name":"Reported by me","jql":"reporter = currentUser() order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-4,"name":"All issues","jql":"order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-5,"name":"Open issues","jql":"resolution = Unresolved order by priority DESC,updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-9,"name":"Done issues","jql":"statusCategory = Done order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-3,"name":"Viewed recently","jql":"issuekey in issueHistory() order by lastViewed DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-6,"name":"Created recently","jql":"created >= -1w order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-7,"name":"Resolved recently","jql":"resolutiondate >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-8,"name":"Updated recently","jql":"updated >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false}]
I do not understand the reproduction steps. there is no "Approve B" in these steps, so I am not sure what you actually do