Bugzilla – Full Text Bug Listing
| Summary: | suppress showing subtasks as children of query if already visible | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||||
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P1 | CC: | ekuleshov, malei76+Bugzilla, mlists, steffen.pingel, tomasz.zarna | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 2.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 202279 | ||||||||
| Attachments: |
|
||||||||
|
Description
Mik Kersten
Created attachment 68758 [details]
Screen shot
Since I belive this is the same situation I have noticed myself, let me add some additional info: With Filter Subtasks option on, subtasks matched by a query are visible as children, but when we collapse the parent task we won't be able to expand it back. The [+] disappears.
I think view filters are disabled when you are using quick find. So, example on your screenshot is showing a valid behavior. If we are able to do this let's make the nesting default. Didn't make it into 2.0. SubTasks will be filtered from the Task List by default. Rob: Looks like recent content provider or interest filter changes caused some problems with when subtasks show up. Marking this as P1 as it would be best to address both of these problems together. Fixed. Created attachment 78025 [details]
mylyn/context/zip
Rob: now that this is done the "Filter Subtasks" action was no longer accurate. I changed it to "Group Subtasks", changed labels, and inverted the check of the preference accordingly. Note that I also changed the preference key and made it on by default now that this bug is fixed. Whether we leave it as the default for 2.1 is still up for debate. I was wondering if the old FILTER_SUBTASKS preference key could be deprecated instead of deleted since I have a connector that is highly dependent on subtasks and therefore had this value set to false on startup. I understand that this is an internal, but I would like to maintain backwards compatibility for users. Is this feasible? Done. We should remove this option for 2.2. (In reply to comment #8) > Rob: now that this is done the "Filter Subtasks" action was no longer accurate. > I changed it to "Group Subtasks", changed labels, and inverted the check of the > preference accordingly. I think "Group subtask" is really confusing. Note that in bugzilla subtasks can come anywhere outside of the project/query, so it is clearly not a grouping. I think "show subtasks" would be more accurate. btw, with last dev build I see 2 levels of subtasks. i.e. bug 196349 Was that intentional? Yes, the goal is supporting arbitrary levels of dependencies. In terms of naming, here are the options we considered. Please feel free to vote for one or suggest another: 1) Group Subtasks 2) Nest Subtasks 3) Nest Dependent Tasks 3) Group Dependent Tasks Note that although "nest" is a good word, it is less obvious than group, and less consistent if we end up with other "group" options, e.g. "Group by <property>". Another constraint is that the option name has to be connector agnostic, and the word "dependency" is Bugzilla specific. Mik, can you please elaborate what is wring with using "show" in relation to the subtasks? So far all kind of grouping been a presentation property (i.e. group by category), so it is completely unobvious and confusing, because this pseudo "grouping" can bring tasks into visibility that do NOT belong to given query. I assume that you are suggesting using "Show Subtasks". The problem with that is that subtasks are still shown (i.e. visible under the query) when the option is disabled. The difference is that they are not nested under their parents, just shown as a flat list instead. So unless I'm missing something the correct verb is one of: group, nest, cascade. I still don't see anything wrong with showing subtasks under query, but "grouping" something that is not even match query criteria don't make any sense, especially after you've been saying for over a year how bad it is to show something that don't match query criteria (i.e. completed tasks under query configured to show only incomplete tasks). Only things that match query criteria should be included in the grouping. Rob: I just checked and it looks like we have a small bug with the guaranteed visibility rule for this. Most cases work, but if I have a task that's matched by a query, and another subtask that should have guaranteed visibility, the task will show as a subtask in a query that it's not matched by. (In reply to comment #18) > Only things that match query criteria should be included in the grouping. I guess we have misunderstanding what subtask is. Let me reiterate and forgive me if I'll state something obvious. It is natural to show all subtasks (even those that don't match query), i.e. some Mylar issue can depend on SWT or JFace fix and it would be confusing and completely unintuitive if task list would show only subset of subtasks under given task node. On the other hand, if one of those shown subtasks does appear in the query results, it may make sense to filter out those, since they will be shown as subtasks under other query tasks. But I am not very certain about that, because it would de-flatten the task list and interfere with planning and prioritization. Constraint is that the option needs to be on when hierararchical mode is enabled, otherwise connectors that opt-out of disabling this option end up with confusing or incorrect UI. Brainstorming more options for the label: 1) Nest Dependent Tasks 2) Show Subtask Hierarchy 3) Nest Subtasks 4) Group Subtasks 5) Show Subtasks 6) Hierarchical Subtasks I think that (3) is the clearest. Rob: given the results of our discussion on the call you should probably ignore my statements on comment#5, which we determined lead to a more confusing UI than they provide benefit. +1 for option (3) Steffen, you mentioned on the call today that subtask 'nesting' should be disabled by default for Bugzilla. Could you provide more motivation for this since were we considering making it on by default for the next release. (In reply to comment #20) > Constraint is that the option needs to be on when hierararchical mode is > enabled, otherwise connectors that opt-out of disabling this option end up with > confusing or incorrect UI. Brainstorming more options for the label: > 1) Nest Dependent Tasks > 2) Show Subtask Hierarchy > 3) Nest Subtasks > 4) Group Subtasks > 5) Show Subtasks > 6) Hierarchical Subtasks > > I think that (3) is the clearest. Clearest, eh? From the http://en.wikipedia.org/wiki/Nest --- A nest is place of refuge built to hold an animal's eggs and/or provide a place to raise their offspring. They are usually made of some organic material such as twigs, grass, and leaves; or may simply be a depression in the ground, or a hole in a tree, rock or building. Sometimes available human made materials such as string, plastic, cloth, hair, paper, etc. may be used as well. --- Sorry, couldn't resist. :-) +1 to either 2) or 5) +1 for: Show Sub-tasks as Tree (to make the wording consistent with the search view) If we don't want a dash in sub-task we should change the JIRA connector to be consistent which is currently consistent with the JIRA web-interface. I am in favor of enabling it by default if the same tasks show up as sub-tasks independently of the query. This option will be somewhat confusing since it will mean something else for JIRA namely to filter sub-tasks from the list. (In reply to comment #23) > +1 for: Show Sub-tasks as Tree > (to make the wording consistent with the search view) I don't think it is relevant to the task list, because Search view is actually flip between flat and tree presentation, but task list still going to use tree. So, we either show subtasks or don't show them. We haven't converged on what to call this option, so we will keep it as Group Subtasks. "Show Subtasks" is inaccurate for Bugzilla so that couldn't be used. "Show Subtasks as Tree" is too implementation-centric because it is about the data structure and not the presentation, and not all users of Mylyn will be immediately familiar with the term Tree. Nest is just a bit weird. "Show Subtask Hierarchy" is pretty good but long, that one could have my vote if we change this in a future releas.e Main work on the bug is done. Note about changing the label added to the Mylyn UI Nits page. Weird, you've been explaining us that bugzilla users does treat those tasks as subtasks, but perhaps "Show nested tasks" would be more generic. (In reply to comment #26) > Weird, you've been explaining us that bugzilla users does treat those tasks as > subtasks, but perhaps "Show nested tasks" would be more generic. Answer to this is in comment#16. (In reply to comment #27) > Answer to this is in comment#16. It depends. Showing things that happens to be subtasks of something else at the root of the query results is a separate story. |