Blocking issues MVC: (add support for issue dependencies)
As a user of issues and epics,
I need to be able to map out dependencies between different issues and epics,
So that I can plan my effort properly through a solid understanding of what sequence the work needs to happen in and what can be done in parallel.
More Details
Currently we allow users to mark issues as "Related to.." another issue. While this is helpful, it doesn't inform me HOW the item is related. Is it related because it's in the same section of code? because it is similar work to effort happening on another section of the product? etc...
To properly enable users to map out dependencies and effort sequencing, they need to be able to mark items as dependent on another item, or that an item is blocking another item of work.
Proposal
MVC: We add 2 additional areas to the issue and epic view, in the same area as "Related to:"
- Blocks...
- Is Blocked by...
We also add some form of visual representation to show the above two states.
Blocked by, Blocks and Related To should all be accessible via the API
Documentation
Documentation would need to be created for this feature.
Acceptance Criteria
- The behavior in the proposal is working.
- Necessary tests added.
- Uses GraphQL first.
- Necessary updates to public GraphQL and REST APIs.
- Telemetry exists to assess feature adoption
- Documentation added.
- Pajamas first. If major changes are required for the graph, consider contributing to the unified dashboard project.
Solution
We are expanding the functionality of the existing Related Issues component by including the ability for users to establish a relationship between issues in one of the following 3 ways:
- blocking
- blocked by
- related to
More than one issue can be added at a time and once added, will display in a newly segmented list below with the same 3 categories.
By default related option should be used (both for existing and new relations).
Feature flag name: issue_link_types
-
Version 1 (latest) Holly Reynolds
- Version 1 (latest) Holly Reynolds
Relates to
- #3358715.53
Activity
mentioned in issue #2078 (closed)
@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!
mentioned in issue #2036 (closed)
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
@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?
-
@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.)
-
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!
marked this issue as related to #2036 (closed)
marked this issue as related to #2036 (closed)
Why is this EEP? People in the blog post are complaining about issue relationships being EEP. https://about.gitlab.com/2017/09/22/gitlab-10-0-released/
-
@dblessing : What do you mean by no auto closing? Do you mean that as a first iteration the auto closing would not respect this blocking relationship? So you would only respect this relationship when you attempt to close an issue manually? (i.e. through a button click or a quick action?) Certainly I think the UI would be easier in that case.
@victorwu I used the wrong term. Instead of auto-closing I mean preventing the closing of a blocked issue. Implement the simple relationship (basically, a related issue with a different name) but don't worry whether a user can close an issue that is listed as blocked by another. We can introduce that in a future iteration since it's complex - see @smcgivern's comment at https://gitlab.com/gitlab-org/gitlab-ee/issues/2035#note_31401778
-
@dblessing : So do you mean we simply create a new section in an issue, called "blocking issues"? (And maybe equivalently, a mirror section called "blocked by issues"?) But the actual blocking mechanism is not implemented until a later time? Wouldn't that be too little functionality? Essentially create just a dedicated area to list a bunch of issue relationships? Which we already have, i.e. related issues.
@victorwu Correct. I don't think it's too little functionality. By default I don't think our leading competitor in issue tracking does anything here, either. They have an option called 'validating issue links'. The basic important piece is having that visual title that says 'blocking issues' - it's much more obvious than 'related issue', which could mean anything.
-
@dblessing : Gotcha. I think that could work. As a middle ground, what do you think of simply displaying somewhere that there's been a violation?
For example, suppose you've entered this relationship: A --> B, i.e. to implement B you really really should first implement A. Or to close B, you really should close A first. Now suppose B is closed, but A is not. Then somewhere in issue A or issue B (or probably both), there's some UI indicating you've violated this intended relationship. The UI is essentially a call to action to tell you to either fix A asap or maybe revert B.
This seems like a very useful feature, and you could simply render the violation when you load the page. (So not a lot of extra effort.) And you don't have to worry about the blocking mechanisms we've talked about above, at least for this issue.
@victorwu I like that compromise. Light-weight, but useful.
+1 for that just having the blocked relationship type is useful.
For us this isn't primarily about blocking the closing of issues but rather about filtering out. I.e. in the normal day-to-day view where we pick up issues to work on we don't need to look at the blocked ones. We try to look quite far ahead and split things up in lots of smaller issues but you can't work on most of them since they are blocked on some issue that needs to be completed first. It's like long chains of issues describing the work. This means we have a good overview into the future but if a programmer just tries to find an issue to work on right now, half of the issues might not be relevant because they are blocked on something else. The blocked/blocking relationship would help us greatly in this area!
Also, I really don't get the EEP status of this, that seems excessive. Issue relationships are in EES, right? So why would a blocking relationship be EEP rather than EES? That's just weird.
mentioned in issue #3254 (closed)
Customer ticket -> https://gitlab.zendesk.com/agent/tickets/89674 (internal only)
added customer label
