|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jonathan Nolen [Atlassian] - 14/May/04 12:57 PM
Also highly similar to JRA-2735
I think a possible way to solve this would be to have a cascade option in the Issue Link. A default value for this can be set in the Issue Link Type and then turned on or off when creating the link. E.g. Resolve, Close, Assignee, Start Progress could update all linked issues. The cascade option would need to be bi-directional e.g. closing parent would close children but not visa versa
Could also introduce the ability to view Linked Issues as if they where part of this Issue e.g. show there comments and update history. Owen suggested that some forum comments from myself and others be added here regarding issue linking & multiple issue updates from a single event.
The original post regarded the maintenance issues with having a single defect being resolved in multiple releases, possible multiple projects. The original poster wanted to extend the status field such that it would be unique to release - so a person could look at a single issue, a single page view, and see the status of the same defect in multiple releases. My primary concern with this approach was that it would lead to an unbalanced model as more data elements were tracked apart from the primary defect. For example, CMVC (IBM, old defect tracking product) uses the concept of 'tracks' within a defect to handle instances of the same defect being fixed in different releases. Each track would have a number of distinct data elements, such as status, comments, owner/assign-to, etc. Additionally, there would be a distinct set of files which were changed (link to source control) to resolve the defect. DevTrack went down this path as well, linking things which aren't defects to a defect in order to get a many to 1 relationship to track fields separately. They are currently suffering from having to support two work-flow integrations (workflow for original defect + workflow for non-defect object child) as well as that none of the user-definable custom fields show up on the linked object. The primary point I'm trying to make is that if you create a different object type and link it to a defect to enable the ability to track data independently of the defect's release, component, or whatever you will inevitably come to the point where you want to treat this 'different object time' as you would a defect. And if it's not a defect, then you have to rework a lot of code to handle it, and support that code. My solution to this problem is to enhance the defect linking functionality to the point where a user could identify, during the linking process, the degree to which the issues would be linked. The issues would still remain distinct/unique records in the database. For example, to solve the dilemma the original poster raised, the user would link two issues and relate all fields except the status field. The user would then be able to view either issue and it would show, in a distinct area on the page view, the different statuses of the linked defects. When the user typed a comment into one issue, that comment would be applied to the other issue. Enhanced linking functionality as proposed by William Crighton would be ideal for my company's needs.
Next question: Would this be defined by the type of the link (sub-task vs. duplicate), or would the user define this link functionality each time a link between two issues is created? Personally, I like the idea of defining which issue properties ripple which way for each "direction" of a link, so that a sub-task would inherit changes from the parent task, and the parent task could inherit certain changes from the sub-task. (Or at least certain events would be fired when the remote end of a link changes, and the local end of the link could listen for, so that plug-ins could easily do things like sum the totals of all the sub-task estimates, etc.) This might be possible with custom plug-ins right now - I don't know yet, as we just started using JIRA last week. Hi Robert,
The functionality to inherit values from an issue has been raised as an issue at JRA-5225. Unfortunately I don't believe that it would be possible for you to create a workflow plugin that will automatically fill certain fields for you. If you were to do this you would most likely need to edit the source code. Thanks, I agree with having a cascade option in the Issue Link but consider the following below.
In our case, what we would like to have for the linking are: 2. For Incorporate link - # 1 applies as well. Therefore, it means that all of these issues (including Duplicate) must belong to one project. 3. For Dependency (Parent-Child) link - the parent issue should not be "CLOSED" unless the child or children issues get closed. This means that the issues can be from different projects. This doesn't mean that parent issue is automatically closed/resolved when the children issues are closed. I believe that if you want children issues to be closed when a parent get closed then these issues must be linked as "Incorporate" rather than "Dependency". OPTIONAL : Thanks, I have added this support request on issue #
https://support.atlassian.com/browse/JSP-16582 this is very important for us. please fix this. -Akshay Hartalkar A possible implementation that would be quick and get us all most of the way there is when resolving, closing, or reopening an issue, any issue, its link type and summary description be displayed in a grid and let us choose with a check box which ones to cascade the change too. This should be very easy to accomplish from a UI and programming stand point and gets us most of the way there.
This is something we could use as well. We are using JIRA Enterprise 3.12.2 with a Commercial license.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Propogate actions/transitions to linked issues
