[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mylar-dev] confusion between task categories and queries
|
Mik Kersten wrote:
We need to keep the UI parts and the infrastructure API parts
separate in discussion of how to improve this support. The UI needs
to be simple and obvious, and the infrastructure needs to be flexible
to support new kinds of connectors. Starting with the UI:
* The fact that queries can only show the tasks from one repository,
and not mix local tasks, provides predictability and simplicity. You
always know that the things that will show up in a query will be the
things that match the query parameters.
That is true, but on the other hand queries are often used in place of
catgories only because there is no other way to get information about
newly created tasks.
So, as we discussed it would be really handy to have another type of
container in addition to query and category that would allow to mix
tasks and query results. That container would allow to automatically
make remote tasks "sticky" when user would open them from query hits, or
otherwise drop hits by marking them as read/uninteresting.
Then my use case with tasks that don't match query anymore dropped
into Archive category should be resolved. Those jumping tasks break
per-category time reporting.
Current workaround to this issue is to use query that would bring all
the tasks (including closed ones), so they would be filtered out by
"closed" filter and still stay under same query folder.
* The user already does not need a query to see changes to tasks that
have been added to a category. All repository tasks with an offline
handler get synchronized every time if they have changed on the
server, no matter where they are.
Not entirely. As it is been pointed out, you can't work with attachments.
* We already do part of what you suggest: every repository task has a
local task created for it, by virtue of AbstractRepositoryTask being
a subclass of Task. That's how the repository tasks get the Planning
page with scheduling and notes information.
Right. I am just suggesting to make those tasks more rich and turn
synchronization into the other way around.
That would better support cases like Raphael were describing.
All it seems like we are missing something in repository integration.
Right now you can have at most one remote repository per task. But what
if I want to have more then one?
That bring us to the idea of task synchronizers. So, each task could
have one or more synchronizers assigned to it. They will sync up this
task with one or more repositories. This actually does not have to
affect current UI experience at all and from the implementation/backend
point of view Mylar already have most of the pieces. In a result,
advanced users will have better control on task synchronization and
allow more transparent integration with tasks managed simultaneously in
Bugzilla/Jira and Outlook/MSProject/iCal.
regards,
Eugene
