Associating a 'Bug' tracker with a Story changes tracker to 'Task'

[SteveCook]

platform: # supported: 2.2.4, 2.3.2
backlogs: # supported: 1.0.5
ruby: # supported: 1.9.3, 2.0.0

Redmine 2.2.4 with Backlogs 0.9.38

We have several trackers that have specific custom fields for gathering useful data (steps to reproduce, et al).
When associating a 'bug' (with custom fields) tracker to a story (identifying the parent story and adding it's id to the parent task field), the tracker is automatically returned as a 'task' and the custom fields and their data are lost.

We have just migrated to Redmine 2.2.4 and are using 0.9.38 of the Redmine plugin.

This was not an issue I had encountered in the earlier version.

[edit patrickatamaniuk: documented relevant versions]

[retorquere]

I don't follow. From the looks of it, you have these three trackers:

• Bug (with custom fields), which is not a story tracker or the task tracker
• Story (no custom fields), which is a story tracker
• Task (no custom fields), which is the task tracker

And when you change an issue from Story to Bug, it's tracker gets set to Task. Is that it?

[SteveCook]

The trackers and the fields you have identified are correct.

However, it's not when I change the tracker, it's when I associate the bug with a story in a sprint:

1. I have a story in a sprint.
2. When I add a bug and make the story it's parent, the bug becomes a task, and the custom fields associated with the bug (steps to reproduce, OS, browser, etc) are then lost.

If the story doesn't have a target/sprint, and the bug is made a sub-task it remains a 'bug' and the custom fields are maintained.

[retorquere]

The latter is actually the anomaly. As far as I know, this behavior has always been this way with Backlogs. Any issue under a story gets its tracker forced to the task tracker. Until the sharing branch is integrated (which has some infrastructure to deal with things like these), this behavior is going to remain. I didn't even know trackers allowed for custom fields.

[SteveCook]

I think there is a perfect storm of changes here - we've recently created a 'support' tracker, and customised the bug tracker to dictate through mandatory fields, useful information that is otherwise overlooked.

I am in a bind, as we have been using these trackers for some time, and there is data associated with them that would otherwise be lost if I removed these custom fields.

Do you have an idea of what kind of time-frame you'd be looking at to incorporate the sharing branch? Or is this likely to be months/year down the track? Of course, we are very pleased otherwise with your excellent efforts to date.. I just need to make a call on how to deal with this (short and long term).

thanks.

[retorquere]

It sounds like a good approach what you've done, so I will have to find a solution. Waiting for the sharing branch is going to take too long. Looking at options.

[SteveCook]

Thanks.
I have also noticed that RM1.4.1 has a bug in the task tracker, that doesn't record data to any custom fields, also (this is isolated to the task tracker only). Just FYI.

[SteveCook]

Hi there - is there any updates to this?

[retorquere]

Sharing has just been integrated, but no updates, sorry, no. Life has been hectic of late, and it admittedly dropped off my radar. I will have to look at it again.

[Cissi]

Hello..

We have the very same problem at my company, we love your application but we miss this possibility.

That is we would also like to be able to add different trackers at least under the task, that is we still want to add task directly under a Story, but once we created a Task with a parent Story, we would like to be able to create children to the task with a different tracker.

The flow will be like this:
We create a Story, and the only children to the Story could still be Task, but if we would like to add children to the task the tracker should not be forced to be a task.

Story

• Task 1
  • Tracker type X
    -Tracker type Y
• Task 2

Story 1 (Tracker Story)

• Child Task 1 (Tracker Task)
  • Child Code Review Request (tracker Review Request)
    • Child Code Review Comment (tracker Review Comment)

We use the plugin Code Review together with backlogs and would like to be able to close all review comments in a task before changing status of the Tracker Task.

Please do not hesitate to contact me if you have any more questions.

[Cissi]

Hello, what is the difference between this issue and issue #184, can anyone explain this for me. In #184 you search for help writing test cases, I can do it if you tell me in which format they should be in. We would like this functionality as we use different trackers for different things see my comment 1 month ago, but adding bug to a story I think is something we might also be in good use.

But as for now we mainly would like to allow Task to have different trackers as childs. Any progress on this and you has marked it as release blocker, what does that mean that next release will contain this functionality.

Best Regards
Cecilia Dahlgren
Project & Quality Assurance Manager
Prevas India System Development Pvt. Ltd.

[retorquere]

I don't know why this is set as a release blocker. There's work being done in this (by me) on the tracker-free-tasks branch.

[SteveCook]

Hi there - hope you're a little less hectic coming into xmas ;)

Any movement on this update? We're currently about to move over to RM2.1.4 and are testing with 0.9.28.
This is critical for us, so it'd be great to get some idea of whether or when it's likely to be released.

thanks...

[retorquere]

Live is crazy right now. Christmas itself will be a little less hectic
because I won't have classes or assignments, but until that time I'm just
barely keeping it together.

On Tue, Dec 4, 2012 at 5:48 AM, stiffy notifications@github.com wrote:

Hi there - hope you're a little less hectic coming into xmas ;)

Any movement on this update? We're currently about to move over to RM2.1.4
and are testing with 0.9.28.
This is critical for us, so it'd be great to get some idea of whether or
when it's likely to be released.

thanks...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/547#issuecomment-10984200.

[cbiggins]

Where can I find more info on the sharing integration? I'll have a look and see if I can get something working.

[retorquere]

It's been integrated and you can enable it in the backlogs settings. No documentation is available right now.

[Cissi]

See this post on the forum for more information.
http://forum.redminebacklogs.net/Usage-of-the-new-functionality-version-story-sharing-tc4025184.html
BR Cecilia
Date: Mon, 10 Dec 2012 16:05:12 -0800
From: notifications@github.com
To: redmine_backlogs@noreply.github.com
CC: mrs_cebe@hotmail.com
Subject: Re: [redmine_backlogs] Associating a 'Bug' tracker with a Story changes tracker to 'Task' (#547)

Where can I find more info on the sharing integration? I'll have a look and see if I can get something working.

          —

          Reply to this email directly or view it on GitHub.

[retorquere]

Can this problem be reproduced on a supported version? The original issue report is about a non-supported redmine version, using a very old backlogs version.

[SteveCook]

Yes it can.
I am running both the latest version of Redmine 2.1.4 with Backlogs 0.9.28 - see my note above.
This is still an issue.
Are you saying that it is not representative of the latest version of the Backlogs plugin? If so, I will pull my developer off this, and submit bugs instead.

[Cissi]

Hello I think my use case is still a problem... See my above comment on the issue.

[retorquere]

Just making sure it's still relevant, I'm doing some triage on the tracker.

To sum up:

Tasks are always forced to the task tracker. Some work is being done to change this, but it doesn't pass our tests so far. No ETA.

There is a known-problem with required fields for tasks when created from the task board. No ETA either.

[retorquere]

Could someone edit the original ticket above to add the version on which this happens? The OP reports this issue on a non-supported version, I can't do anything about that.

[SteveCook]

OK - I did update the versions in the original ticket (as requested) and suggested up thread that it is still an issue with the latest supported version. We are still stuck with this major issue with the Backlogs plugin. I have zero resource availability to fix this locally at present - so please update this ticket to let me know if there is ANY likelihood that this issue will be rectified in the future and an ETA (if at all possible).

Our current set up is:

Environment:
Redmine version 2.2.4.stable
Ruby version 1.9.3 (i686-linux)
Rails version 3.2.13
Environment production
Database adapter Mysql2
Redmine plugins:
redmine_backlogs v0.9.38
redmine_boards_watchers 0.2.5
redmine_contacts 3.2.1-light
redmine_github_hook 0.1.1
redmine_lightbox 0.0.1
redmine_plugin_views_revisions 0.0.1
redmine_timesheet_plugin 0.7.0

[d5han]

Is there any update on this? I'm looking to make use of child objects on stories that aren't tasks.

I've been searching through the code for a while, but the RbTask.rb model seems to require that "tracker=Backlogs.setting[:task_tracker]" else backlogs will assume it is not configured and hide itself, and I didn't have any luck removing the configuration check.

I'm no expert on ruby, but I'm looking for a way to prevent these different child objects from being forced into tasks. They don't need to be treated as tasks at all by backlogs.

[d5han]

I found a fix. In ../htdocs/plugins/redmine-backlogs/lib/backlogs_issue_patch.rb I commented out a few lines in the backlogs_before_save function and edited the sql query in the backlogs_after_save function that set the tracker and fixed_version if the item was labeled a "task". Now stories can have non task children, but these children are not tracked as tasks in things like the taskboard.

[Edouard-Barthuet]

Thanks DaveKSh.

Here is the changes I made and tested following your advice.
This way the tracker is not updated when a ticked is assigned to a feature.

in backlogs_before_save
--> FIX: DO NOT FORCE TRACKER OF SUBTASKS IN FEATURES TO TASK
Comment the following: self.tracker = Tracker.find(RbTask.tracker) unless self.tracker_id == RbTask.tracker

in def backlogs_after_save

--> FIX: DO NOT FORCE TRACKER OF SUBTASKS IN FEATURES TO TASK
tasklist = RbTask.find(:all, :conditions => ["root_id=? and lft>? and rgt<? and
(
(? is NULL and not fixed_version_id is NULL)
or
(not ? is NULL and fixed_version_id is NULL)
or
(not ? is NULL and not fixed_version_id is NULL and ?<>fixed_version_id))", self.root_id, self.lft, self.rgt,
self.fixed_version_id, self.fixed_version_id,
self.fixed_version_id, self.fixed_version_id]).to_a

...
connection.execute("update issues set
updated_on = #{connection.quote(self.updated_on)}, fixed_version_id = #{connection.quote(self.fixed_version_id)}
where id in #{task_ids}")