Unstage declined requests #8946
Conversation
DavidKang
added
Frontend
|
not sure I'd want that - at least in ADIs I often have a group of stuff relying on each other, and a decline means I need a fixed submission incoming - that should go to the same adi group the original thing was in. In case of 'Project based Stagings (think full KDE Stack, Full Qt update) it's the same thing - one request being declined means the full group is only ready when a fix is incoming for that group |
|
Hey @DimStar77 any idea how to handle it? Another solution would be to avoid decline a request if it's staged (look the issue that we are trying to fix #8757) but then it wouldn't be in line with the #8941 |
Clearly not an option - legal as well as the regular source review must be able to decline a request irrespective of it being staged or not. |
|
declining and accepting are clearly 2 different beasts. For a declined request, the manual unstage needs to manipulate the reviews. The declining action itself should not touch it |
I don't really know how you are doing staging, but I was assuming that you just stage a request after those checks are done (as in a CI pipeline), no? |
|
https://stephan.kulow.org/mermaid.html happens all in parallel |
|
Well I push a second commit where the reviews are handled during the unstage process. The only thing is that I reopen the request to be able manage the reviews. I reopen the request, because I don't like the option to skip validations/policies on requests and reviews. |
thanks |
|
That will do. Thanks |
DavidKang
force-pushed
the
feature-unstaging-declined
branch
3 times, most recently
from
bdaa1a0
to
9cf0cd2
Compare
DavidKang
added
review-app
When a request is on a declined state, we can't touch the reviews. For that, we reopen it temporally to manage the reviews.
DavidKang
force-pushed
the
feature-unstaging-declined
branch
from
9cf0cd2
to
31cac33
Compare
| login user | ||
| bs_request.change_state(newstate: 'declined', user: user.login, comment: 'Fake comment') | ||
| delete :destroy, params: { staging_workflow_project: staging_workflow.project.name, format: :xml }, | ||
| body: "<requests><request id='#{bs_request.number}'/></requests>" |
There was a problem hiding this comment.
see the "test case" in the feature request. The interesting part is if reopening the request leaves the staging project untouched and the request will appear in backlog.
I expect this to be the case, but it would be good to have this future safe.
There was a problem hiding this comment.
@coolo, what do you mean with untouched?
I extended the test, reopening a declined request that was unstaged.
There was a problem hiding this comment.
untouched == it stays empty after reopen if it was empty before. Just as your test verifies
DavidKang
force-pushed
the
feature-unstaging-declined
branch
from
31cac33
to
a74c020
Compare
DavidKang
force-pushed
the
feature-unstaging-declined
branch
from
a74c020
to
38628ef
Compare
Request that was decline can only be reopen by the user that decline it or you have rights on the target package. Staging Manager should be able to reopen the requests and change the reviews to send the declined request to the staging backlog if this request is reopened.
|
By this the 'untracked' state should be impossible to reach. |
This state should be impossible to reach after openSUSE#8946
When a request is on a declined state, we can't touch the reviews. For that, we reopen it temporally to manage the reviews.
Fixes #8757
TODO: