It's all about the answers!

Ask a question

Default Filed Against (Category) field for work items created within a plan

Patrick Paquette (371219) | asked Sep 23 '13, 10:16 a.m.

I've read that the default Category for work items created in a plan doesn't use the defaults created for the project (described here  I can't seem to figure out how Jazz determines the category for work items created from within a plan, and how one can control this.  For example, when we're in a plan and create a new one for a developer, it sets up some of the fields by default properly (like iteration and owner), but the category.

This is close...

And states that the category is coming from the project configuration somewhere?  I have no teams setup...

Millard Ellingsworth commented Sep 23 '13, 8:42 p.m.

Hi, Patrick. Can you provide some more details? What version of RTC? Are you using the Eclipse or Web Client? It sounds like you have multiple categories but no team areas. Do you have more than one timeline? Are you wanting to understand or coerce the behavior?

Patrick Paquette commented Sep 24 '13, 9:14 a.m.

 RTC 4.0.3.  I know this happens on the web client, haven't tried it on the eclipse one.  I do have multiple categories and no team areas.  Only one timeline.  I'm wanting more of an understanding and a recommendation on how to use RTC based on the way we work...we want to categorize things based on the subsystem, but everyone on our team is concerned about it.  On any given iteration, we can work on multiple subsystems, so there's no distinct timeline.  Each release may or may not release the deployable artifacts of each subsystem, but they are all done together in one big shot (allowing for sharing of documentation like release notes).  Categories is what I thought would be best for this to help with searching, but maybe what I really want to use is tags, and remove the category field all together, because we're not using the separate teams/timelines?...hmmm...opinion?

Millard Ellingsworth commented Sep 24 '13, 10:13 a.m.

I generally recommend at least 1 team area (for the reasons outlined here).

I think you are on the right track -- categories are meant to provide a separation of concerns, if you will: this issue is related to the planning widget, that one with the date-time control in the web UI, that other one with the build system.

When you say "I know this happens...", what is "this"? I'll hazard a guess: From the web UI, the work item is added to the plan with just a type and a summary, the other details filled in or defaulted in some way. For example, if you have the plan grouped by user and add an item under a user, the Owned by will be set to that person. I'm guessing that when you open that item, you are surprised by the Category chosen for the Filed Against attribute. Non? 

Patrick Paquette commented Sep 24 '13, 10:43 a.m.

Your example is exactly what I'm talking about (it's "this").  I don't understand what RTC is using to determine the default the category when creating a WI from a plan in the work breakdown view by clicking the create item button beside a user when there are no Team Areas.

Patrick Paquette commented Sep 24 '13, 10:43 a.m.

This link doesn't really say "why" we need to make a Team Area...the section"Create and associate a work item category with the team area" states it merits a whole other article - is there such an article?  In any case, if I make a Team Area and do this association, that'll probably do it, Non? 

Millard Ellingsworth commented Sep 24 '13, 11:02 a.m.

The main "why" is separating the workers from the watchers. If you have stakeholders, you may have noticed that they appear in your plans even though they will never get assigned work. Changing this later in the project if you suddenly start taking on stakeholders is non-trivial. No, I don't think creating a team area will just fix your concerns (see answer below).

showing 5 of 6 show 1 more comments

Accepted answer

permanent link
Ralph Schoon (63.3k33646) | answered Jun 23 '16, 4:38 a.m.
edited Jun 23 '16, 4:39 a.m.
Look at:

The category is assigned depending on the plan owner. The algorithm picks the category which is:

1) Closest to the root
2) Assigned to the owner (team area)

In the case when there is no category assigned to the process area, the algorithm picks one from the whole hierarchy. The algorithm never picks the unassigned category.
Ralph Schoon selected this answer as the correct answer

Ralph Schoon commented Jun 30 '16, 3:04 a.m.

3 other answers

permanent link
Nicholas Carbone (6168) | answered Nov 13 '13, 12:09 a.m.
Correct or not, I've found that the category is defaulted to the alphabetically first category available for the plan scope.  I believe this covers both when you do and do not have team areas defined.  I've also found a case where the default is something not within the scope (but that must be a bug).

permanent link
Millard Ellingsworth (2.5k12431) | answered Sep 24 '13, 11:25 a.m.
If you create a work item (not from a plan) there is a "Guess Category?" link (described briefly here -- look under Automatic Work Item Categorization). I imagine it is guessing for you when creating an item from a plan. At that point, the only data it has is the person you assigned it to and the summary. Depending on how much it can glean from the summary, the results may vary.

Another mention of the feature I found says "Since this feature uses the fulltext service to derive the category from similar work items, it works best if the description attribute is rich in content." Unfortunately, when adding from a plan, there is no description yet. I presume it is also using the summary field but I could be wrong.

Filed Against is often a required field and if "Unassigned" is not valid, some sort of guess is necessary or the new work item cannot be saved (which may cause the plan to not be saveable). While it is difficult to generalize across our user base, I think it is common for a team/project to be associated with a relatively small number of categories, perhaps even just one (which makes guessing correctly quite easy).

We could file a work item to improve the guessing but it could still end up wrong -- which means we do a bunch of work and nothing gets better. You could write a default value provider that could coerce the Category (though you are now always choosing the same one or the onus of guessing is shifted to you). I'll spin up a short experiment to see if I can think of something else.

Millard Ellingsworth commented Sep 24 '13, 3:00 p.m.

I created a scrum project area and setup 5 categories with no teams. I brought up the Sprint Plan and added some work items, trying to put certain words in the summary and assigning to certain categories, hoping to get the system to "learn" that if "Marco" was in the summary, it was likely to be in category Subsystem2 and if "Subsystem3" was in the summary, the category should be Subsystem3. Then I added more tasks using the clues. Every item I added defaulted to Subsystem1, the first category in the list (that wasn't Unassigned). In my example, "Unassigned" is the root category and all others are direct children.

I then added some similar text to the Description of all of the items assigned to Subsystem2 in hopes of seeing the suggested category change. Still always defaulted to Subsystem1. At least for my simple case, I'm not seeing any interesting behavior at all.

permanent link
Murat Isleyen (191620) | answered Jan 21 '14, 10:30 a.m.
Hi all,

Any progress on this issue?

I have encountered the same situation on a project. The category (filed/against) information is determined by the category association when creating a workitem under the plan view.

If no association is assigned, I think the first line in the category list will be selected.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.