http://forum.redminebacklogs.net/Tracking-issues-with-parent-track-td2765236.html
Not sure if this is a bug or by design: My backlogs is tracking user stories, tech stories and tasks (as task tracker). Whenever I create any of this as a sub-task (ie: assign some task as parent) the item no longer shows up in the backlog tab.
Is there a way to change this behavior?
私のBacklogsでは、ユーザーストーリー、Techストーリーとタスク（タスクトラッカーとして）をトラッキングしています。
その際、タスクを子タスク（つまり、親としてあるタスクを割り当てています）として作成すると、この子タスクがバックログタブに表示されません。
これがバグか、設計によるものかはわかりませんが、この振る舞いを変更する方法はあるでしょうか？
This is intentional behaviour.
As a product owner you don’t want to see tasks and tech stories in your backlog. As a team member you can see all the tasks on the taskboard of the current sprint.
これは故意の振る舞いです。
プロダクトオーナーは、バックログでタスクおよびtechストーリーを見たくありません。
チームメンバーは、現在のスプリントのすべてのタスクをかんばん上でみることができます。
Ok, but wouldn’t`t this relate to the tracker type only? Having parent/child user stories are common way of working with Epics or other grouping techniques. I don’t see how parent/child infers a tracker type in a safe manner.
Is there an easy way for me to pacth it (I’m not much of a rubist myself)?
OK。しかし、これはトラッカータイプのみに関係があるのではなかったでしょうか？
親子関係のあるユーザーストーリーは、エピックもしくは、その他のグルーピング手法を用いて運用するという認識です。
私は、トラッカータイプでどうやって親子関係を安全に表現するのかわかりません。
私が簡単にパッチを当てる方法はあるでしょうか？
（私自身はたいしたRuby使いではありません）
Not an easy way, no. The current behavior forces any issue that hangs under a story at any point to a task, so “sub-stories” get forced into tasks as well. I did as a convenience because otherwise you’d have to be careful to select the right (task) tracker type for each task you create.
It would be possible to only enforce this for issues that actually have a story-tracker assigned, but right now there’s the built-in assumption that a Story has one of your story-trackers attached _and_ is a top-level issue. The 2nd assumption can be removed but only with a) (slight, I would guess) performance impact, b) great care, and thus c) accompanying unit tests.
Feel free to create a feature request for this in the tracker. I’m open to doing this, but I have limited time; don’t hold great expectations of “soon” unless someone submits a patch.
簡単にパッチを当てる方法はありません。
現在の振る舞いは、ストーリーの下にサブストーリーを作成すると、強制的にタスクに変換されます。
そうしなければ、タスクを作成する際に、正しい（task）トラッカータイプを選択するように注意しなければならなくなるからです。
実際に、story-trackerの割り当てが抱えているこの問題を解決するためだけに、機能を強化することは可能でしょう。
しかし、今ちょうど、ストーリーの子チケットとしてstory-trackerのうちの１つがあるという仮定があります。_and_ を付けた、トップレベルの問題です。
第二の仮定は、削除することができます。しかし、下記の場合のみ。
a)(少し、私は推測しましょう)パフォーマンスへの影響。
b)ゆえに大きな注意がいる。
c)添付のユニットテスト
必要と感じるならば、このトラッカーに自由にfeatureリクエストを作成してください。
ただ、私の時間も限られています。
「すぐに」実現して欲しいという大きな期待があり、なおかつ、誰もパッチを提供しなければ、私はそれを開いて、着手します。
Thanks for the help and for the clarification. I’m not much of a fan of breaking behavior that was by design without a good impact analysis. Those are the thinks that will bite us in future so I’ll look int other ways to manage my needs using redmine custom fields. 🙂
問題について解析してくれてありがとうございます。
私は現在の振る舞いを壊して、代替となるより良い設計を提供できるほどの熱心なファンではありません。
Redmineのカスタムフィールドを活用することで私の希望するマネジメントを実現できないか検討してみます。
I’ve just checked in a change that will allow stories to have parent tasks. It passes all our current tests but has of course seen very little real-world use so far. The behavior that forces all issues under a story to the task tracker remains, so an issue tree can have only one Story.
たった今、storyが親タスクを持つことを許可する変更をチェックインしました。
手元のテストは通っていますが、ありとあらゆるパターンを試しているわけではありません。
storyの子チケットを強制的にtaskに変換する振る舞いは残ります。
したがって、チケットの親子ツリーには１つのstoryだけを持つことになります。
コメントを残す