GitLab.org / GitLab Enterprise Edition

added Discussion EE Starter issues labels

changed milestone to Backlog

added coming soon label

added direction label

added to schedule label

mentioned in issue #2078 (closed)

mentioned in issue gitlab-ce#31583

mentioned in issue gitlab-ce#14232

Could this be slightly expanded to also block merge requests from merging (through the gui) when there are blocking issues (other merge requests); it shouldn't take much longer then implementing the original scope

mentioned in issue gitlab-ce#32023

mentioned in issue gitlab-ce#18345

@jonas1 : Yes I think so. We might actually need to include that, depending on the implementation, becasue of auto-closing. I.e. we can't claim "blocking" if it doesn't block auto-closing mechanisms. I'll update the issue accordingly. Thanks!

added EE Premium and removed EE Starter labels

changed the description

Why was this moved to EEP from EES? Is it really that much of an advanced feature that it needs to go in the premium package?

mentioned in issue #2036

mentioned in issue #2001 (closed)

@smcgivern / @sarrahvesselov : We should probably solve the auto-closing and general UI problem here. Thoughts? My proposal is the following:

• Issue A blocks Issue B. Equivalently, Issue B is blocked by Issue A.
• If Issue A is open, Issue B cannot be closed. Issue B can be deleted.
• Consider a merge request. Inside the merge request, you indicate "Fixes #B".
• Update the merge request text copy to say, "Attempts to close Issue B".
• When the merge request is merged, suppose Issue A is open, then Issue B remains open.
• The merge request says text copy says, "Issue B was not closed".

• Subsequently, Issue A is closed. Issue B remains open. You can now manually close it.

• Update the issue UI so that the close buttons do not appear.

• Update so that the close slash command does not appear.

• Update the API so that close requests are rejected.

added UX label

mentioned in issue gitlab-ce#4058

mentioned in issue gitlab-ce#20135

mentioned in issue gitlab-ce#21453 (closed)

@victorwu I'm not sure that covers @jonas1's request, which is to prevent an MR from being merged. (My personal opinion is that this shouldn't be in the first iteration - there are already lots of ways to prevent an MR being merged, and the relationships we have are only between issues.)

• If Issue A is open, Issue B cannot be closed. Issue B can be deleted.

I assume that if issue A is closed, then issue B is closed, then issue A is reopened - issue B is not automatically reopened?

Similarly, if issue B is already closed when it is set as being blocked by issue A, it can be reopened, but it can't be closed if it's then reopened until issue A is closed?

• Update the merge request text copy to say, "Attempts to close Issue B".

This needs an extra line:

• Issues that will be closed.
• Issues that are mentioned but will not be closed.
• Issues that would be closed, but currently can't be because they are blocked.

Is that worth it for the first iteration?

• When the merge request is merged, suppose Issue A is open, then Issue B remains open.
• The merge request says text copy says, "Issue B was not closed".

We don't actually move this to past tense at the moment. Doing so accurately isn't trivial: what if someone closed the issue just before you merged the MR?

All other issue tracker I know (bugzilla, redmine, ...) don't enforce transitivity. Sometimes, blocking bugs are used to track regressions. Sometimes, blocked bugs are meta bugs, and can be closed when the major blockers are done.

@smcgivern : I wasn't trying to solve the blocking mr merge problem. Definitely I agree we should try to get the smallest version in first. So the mental model I have is that the "blocking" constraint is only considered and enforced when there is an attempt at closing an issue. So I was trying to enumerate all those possible events. Definitely I think enforcing it as an ongoing state would be too complex as a first iteration.

At least this is what I think from a simple first iteration in terms of product complexity and implementation complexity. Please let me know if it doesn't make sense technical-wise.

So with that in mind:

I assume that if issue A is closed, then issue B is closed, then issue A is reopened - issue B is not automatically reopened?

Totally. This is an edge use case. Since B is already closed, I don't consider it at all. I only consider what happens when I attempt to close B.

Similarly, if issue B is already closed when it is set as being blocked by issue A, it can be reopened, but it can't be closed if it's then reopened until issue A is closed?

Yes again! In my mental model, I only consider the constraint when closing B. Re-opening B is not part of the constraint.

Regarding merge request and the words there, we can figure out what to put in terms of text copy and what's feasible later. But I wanted to at least figure out what is feasible in this first iteration. One possibility is to totally ignore auto-closing in the constraint. That is, in my model above, I consider only the action of manually attempting to close B, and it is blocked / prevented. We can release a version to say if B is auto closed via a merge request, the blocking constraint doesn't consider it, and therefore, it can still be closed via merge request. I think ideally we wouldn't want that and we could prevent that from happening in the first iteration. Thoughts?

@victorwu I wonder if we could go the other way, and just not deal with the MR widget text, but still enforce the constraint on closing a blocked issue?

@smcgivern : Sure. I don't see the widget text as being a huge problem anyways. But what do you envision regarding the auto-closing feature in the first iteration? I.e.:

• Issue A blocks Issue B.
• Issue A is open.
• Issue B is open.
• MR C is marked with "Closes Issue B"
• When MR C is merged, what should happen to Issue B?

@victorwu I think that if an issue can't be closed by you because it's blocked, that should apply everywhere (UI, API, MRs, commit messages, etc.) 👍

changed the description

Thanks @smcgivern.

@sarrahvesselov : We'd need some UX design for blocking issues to review just the concept, and the many places it impacts. Probably earliest we'd work on this is 9.5. I can ping you again when we are more certain we want to action on this.

Please do @victorwu. Thanks!

changed milestone to Next 2-3 months

removed coming soon label

mentioned in issue gitlab-ce#31129