|
[
Permalink
| « Hide
]
Scott Anderson added a comment - 06/Dec/04 09:25 PM
I think sub-tasks should also (optionally) inherit the version information as well. A sub-task that isn't slated to be released in the same release as the parent task doesn't make a tremendous amount of sense to me.
I believe that subtasks should inherit everything from their parent issue, as Charles says, it's particularly important when using that 3 field form. on the parent task.
So, votes for: component, affects version, fix version to be inherited. The other thing that I'd like to be able to inherit is the assignee. We are using subtasks as a programmer's "todo" list on the current issue. If they don't change the assignee off of "automatic", then it gets assigned 'back' to me, as the project lead. I'd like to see one of two things: A user has noted that they would like the subtask 'create issue' form to be prepopulated with the parent's values, which the user can then change if necessary.
Hi,
This issue has been documented at JRA-5225. Comment and vote on this issue if you wish. Thanks, Same improvement
I strongly second this proposal: subtasks should inherit everything from
the parent task by default. Creating subtasks would thus become several times more efficient. Is this likely to be on a future release or should we just start developing a custom workflow plugin now?
Willie,
This probably won't be in the next release so I'd develop your own I guess we should clarify the requirements as it stands.
The key point I want to clarify here is that the sub task fields are not linked back to in anyway to the parent issue; the feature is a usability enhanacement rather than data integrity assurance. Changing the parent issues' affected version will not change it for a sub-task. IMO, this solution will solve the problem for most people and will remain relatively simple to implement. How does this fit with the requirements of people out there? It's exactly the behaviour that we want.
If this solution is accepted, in which release it will be available? Just a note: "default to the value" should mean that on the subtask issue details page, the parent's values should be selected by default, not that whatever values the user enters get silently ignored in favour of the parent's (as a post-function implementation would achieve).
We would really like it if it was also possible to optionally apply parent changes to the sub-tasks. It would also be good to be able to bulk-change the sub-tasks in the event that they were out of synch.
> Dear JIRA Support:
> > Here is a suggestion / feature request: > > FEATURE DESCRIPTION: > (a) Would be very useful if a JIRA user could turn this feature "on" > or "off" at a GLOBAL level (ie it becomes a default or not a default > setting for all sub-tasks) > (b) Would be also nice if the JIRA user could also turn this feature > "on" or "off" at a LOCAL level {{ ie on a per item basis, thereby > allowing the user to override, for that item only, the global default > setting from (a) }}. > (c) The feature is as follows: When creating a subtask, the subtask > will automatically inherit all the properties of its parent item (eg > all components will be selected as per the parent item, etc, etc, etc) > (d) To make this a super-feature, the JIRA user could specify in the > general settings area of JIRA, how many parameters from the parent > item should be automatically populated into a sub-task !!!! - now that > would be nice. I agree thtat the sub-tasks should inherit all reasonable values from the parent such as components, version, due date and priority. In particular, I am finding that I have to run around and fix the components and versions of the sub-tasks that my staff set up. Many of the staff work at the task level, and they just care about the tasks assigned to them. When they bring up the task, they see the sub-tasks in it and don't really notice that the components and versions have not been set. When I supervise the projects, though, I see lots of sub-tasks without a component and which are unscheduled.
Hi all,
1) this feature should be enabled or disabled by the administrator (maybe on a project, issuetype basis, ...) 2) when this feature is enabled, the system should let the administrator choose which fields are concerned by "the inheritance" ( this feature must not be an "all or nothing" feature) Cheers, To expand on what Pierre-Yves said, you could have a Field Inheritance Scheme which is configured similar to the way that an Issue Type Scheme is, and that is to simply select a set of fields which are in the scheme, and which get inherited by sub-tasks.
You then add an Issue Type Field Inheritance Scheme which maps issue types to a Field Inheritance Scheme. You then allow an Issue Type Field Inheritance Scheme to be attached to a project. As a simplification, you could just attach a Field Inheritance Scheme to a project and forgo implementing the Issue Type Field Inheritance Scheme. We need this feature too. But we want also that a change in parents issue DOES affect changes in child sub-task. This is really needed for fix version (otherwise a release planning is not really effective).
ANd the inheritation should not depend on the sub-tasks screen. I don't want the users for example change the fix version of a sub-task but I definitely need it for the parent issue. Would very much like to hear if there is any new considering for adding this. We're using sub-tasks as a lite-wight alternative to cloning issues (same defect fixed in different versions) and would like to have this available to us. Cheers.
Another issue related to this, is that if you need to change the fix version of the parent issue its really difficult to also change it for the sub-tasks. If the inhertied fields are enabled they should also be updated on edit. The inheritance shouldn't only be at creation time.
Another vote on the definition specified by: Mark Chaimungkalanont - 27/Jun/05 02:43 AM
If we end up having to roll-our own solution due to a lack of statement about when this might make it into a release, we will probably implement this way: [] Create a custom field with known state values ("Roll-up", "Roll-Down", "No change"). We will probably end up scheduling this periodically so that only issues that changed in the last period are examined and the end-user community would be just be made aware that data will be updated over a reasonably short period of time and to not worry about the details (which they mostly don't anyway). Just to put our voice in there too.
This seems like a no-brainer. If we don't have the functionality of JRA-3374, we at least streamline the existing sub-task concept.
Often, issues affect a specification component, design component(s), and a user manual. When I have a single issue associated to several components, I want to be able to one-click create subtasks, one for each component, such that each subtask inherits from the parent issue EXCEPT for components and assignee. I want each subtask associated to only one of the multiple components from the parent, and thus to be assigned to the component lead for that component. With the introduction of plugins like GreenHopper, which allows drag and drop assignment of versions to an issue, this becomes even more imperative since once an issue is assigned to a version and a subtask is created afterwards, the subtasks stays with no version assigned. Therefore, even though the parent issue has been scheduled to be released in that version, it's subtasks are unscheduled. You have to go and manually drop it onto the version in GreenHopper.
At a minimum, if a post transition function were provided to be able to do this, even that would suffice. Agreed. The one-click subtask feature is useless for us without this.
I'll just echo what others have said. When using sub-tasks for creating a hierarchical WBS, a sub-task is always truly contained by its parent. All kinds of possible data integrity issues, but this inheritance issue is certainly critical.
Devil's advocate – this seems straightforward enough to hack in there via stored procedures and triggers on the database itself. Outside of the obvious portability issues between versions, any reason this would be outright dangerous to data integrity? Steve,
JIRA relies on a (Lucene) index for a lot of its functionality. All searches, statistics, reports, and other functionality depend on the index being up to date. Database stored procedures will only update the data in the database. There are also other more subtle reasons. I guess you would also need to setup your Screens such that for sub-tasks the version and components fields do not get updated. If you do this, however, there will still be other parts of the system that get around the stored procedures. For example, when bulk moving issues between projects, the version felds (Affects Version and Fix For Version) need to be updated. JIRA will prompt the user for this data for the parent issues and all sub-tasks. The parent issues will be updated first, and the stored procedures will fire. Then the sub-tasks will overwrite the values set by the stored procedures, which is a problem if the user chose a different value for the sub-tasks. There are probably other issues, but these were the first ones I thought of. Cheers, I've had users request that 'watchers' be among the attributes inherited from the parent task by the sub-task.
Would it not be easiest having a post function for workflows that can copy a value from another field in the main issue?
There is already a function called Copy Value From Other Field, but only fields within the same issue are available. You could use this function in the creating step but I can imagine situations later on in the workflow when this could be useful, too. A function like this would allow configuring in detail which field values to inherit and when to do this. I'd like to add my voice to this cause as well. We could really use it.
This feature would be a real time saver in our workflows. I hope it gets added.
I created a JIRA yesterday about this because it was killing me to have to update all these attributes. How I would optimize the work flow for adding a subtask.
If we don't automatically inherit parent attributes, on the Add a subtask part of the parent page, simply have a link "Inherit parent attributes" that lets people do it with one click. It would also be very helpful to have the description field in this little widget so we don't have to create the task, then go into the subtask, and then another click for editing. Having another textbox called description that grows as you type into it would save real estate and be a real time saver for the creation of subtasks. Need to inherit all the fields to simply this, and then users can edit or bulk change. Otherwise you fall into the problem of trying to judge which fields are critical to us.
Also, when users change parents, the subtasks should automatically follow (components, versions, etc.) When planning a fix version it is really missing that I do not have a filter to find al the subtasks that are in that version. Because the subtasks fix-version is not inherited.
I can even do not do a bulk update of all the subtasks of a fix version to put them in the correct version because I can not select subtasks that belong to issues of a particular fix-version. I need to update (and keep updating) fix versions of the subtasks every time the parent issue version changes. This is really a burden. Inheriting fields like the fix version would really make life easier. I created and attached an IssueEventListener that intercepts two events:
Upon one of these two events it will inherit the Fix-Versions and Components field from the parent issue to the subTask(s). This is example code and should be optimized for production. Maybe somebody has time to create a nice plugin? These fields should be hidden from the subTask create and update screen because they would be overwritten anyway. And that would be confusing. Only use them for filtering! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Sub-tasks should inherit component and version of parent task
