Re: Comments

Hi Tor,

Tor Norbye wrote:
>> However I see that the source tasks are "derived". Their primary 
>> source is application source code. So the persistent store for them 
>> would function more like a cache for these tasks. MDR could be a good 
>> place for storing and managing them.
> 
> Ah, perhaps you can contribute the code for that :)

I can do that if you want, I am just not sure if you would like to have 
that functionality in your module.

>> 3) Suggested tasks:
>> Context pop-up menu item like "Autofix" seems natural to me. Another 
>> possibility is to have a column (next to Done) with "Autofix" button 
>> for each task.
> 
> Ok. Perhaps if the exact name for the "Autofix" action was done on a per
> action basis (by the providing module) it would make more sense, e.g.
> for an import tool action, it could be named "Import".

I think that this is not needed. From the task name (e.g. Missing import 
for xxx.) it is quite straightforward what Autofix means. I think it 
will be more intuitive. Having different menu item names for each task 
may confuse users.

>> 4) Categories:
>> Another approach would be to have only one task list for user tasks by 
>> default (named User Tasks as now) and give users option of creating 
>> custom task lists of the same type. So that someone could create a new 
>> task list (based on User Tasks task list) and name it e.g. "Issues".
> 
> Yes, I've thought of this possibility - it makes a lot of sense in
> the issuezilla view case: I'd like to be able to create multiple
> windows, one for each query (e.g. one window for my open bugs, one
> window for all unassigned bugs in a category I work on, etc).  The
> alternative is to use the subtasks mechanism to create query nodes
> in the bug view, and have the bugs under each query. This means fewer
> windows (good) but not as user friendly (more scrolling, more node
> expansion).

Yes, this would be cool. I like more the first option (separate 
windows/task lists).

Martin