Support Forum

[victor]

Yes, the problem is that next version is scheduled for next year and I should need to find a solution for the jump list and the move action before december.

OK, if you suggest how we should name checkboxes - we'll implement solution with 2 checkboxes in 2.8

Possible, "is Project" and "is Container" should be understand-able, right ?

Uhmm... project and container are very similar... What about convert project to a list field named relevance?

Relevance: Task (0), Subproject (1) and Project (2)

Move-task list: Show tasks with relevance>=subproject.
Default-project list: Maybe like move-task.
Jump-to list: Show tasks with relevance>=project.

But wait a moment.

Recently I tried to put all (my project and subproject categories) with the project attribute enabled and I saw that the list is sorted by name. If we have a long list (like the proposed for move-tasks) and we have two items with the same name and want to select one it will be a bad joke because we have not contextual info.

I dont want to press you about to do a task lists improvement now. I understand that this is not a trivial thing and I prefer wait to solve it completely in the 3.0 version to delay the actual 2.8 version.

I think that a good solution could be:
- Substitute project by relevance attribute.
- Mantain jump-to list for relevance>=project tasks.
- Move-task and default-project lists for relevance>=subproject and a with like-a-tree sorted method

If you think that this is easy to do ok, do it. But If this is not 'so easy task' wait to analize this solution for the next version I am not desperate with it, ok?

Thanks for your impulse

[admin]

Uhmm... project and container are very similar... What about convert project to a list field named relevance?

Relevance: Task (0), Subproject (1) and Project (2)

Move-task list: Show tasks with relevance>=subproject.
Default-project list: Maybe like move-task.
Jump-to list: Show tasks with relevance>=project.

But wait a moment.

This scheme looks fine for your task, but why only 3 relevance levels - what difference between subproject and project, for generic installation ?

Also, often things can be 1,2, or n, possible we'll need to configure relevance levels behaviour later

Recently I tried to put all (my project and subproject categories) with the project attribute enabled and I saw that the list is sorted by name. If we have a long list (like the proposed for move-tasks) and we have two items with the same name and want to select one it will be a bad joke because we have not contextual info.

I dont want to press you about to do a task lists improvement now. I understand that this is not a trivial thing and I prefer wait to solve it completely in the 3.0 version to delay the actual 2.8 version.

I think that a good solution could be:
- Substitute project by relevance attribute.
- Mantain jump-to list for relevance>=project tasks.
- Move-task and default-project lists for relevance>=subproject and a with like-a-tree sorted method

If you think that this is easy to do ok, do it. But If this is not 'so easy task' wait to analize this solution for the next version I am not desperate with it, ok?

It seems that we need some time to think. Its difficult for me to determine right solution now because we (internally) has no such problem and I know no other users that have such problems. Often if somebody need some small checkbox "here and here" this mean that some major redesign (that solve many other problems too) required. The same problem with your workflow suggestions, by the way - too low amount of suggestions about our workflow engine from different users.

Thanks for your impulse