Support Forum

[victor]

Hello,

I have a problem with moving tasks: I like to move tasks but I only can move tasks to 'project' tasks.

When I say 'project' tasks I am meaning a category of task with the project attribute enabled.

I could do all my project folders to be 'project' tasks but then I should have an useless 'jump by alias' listbox.

I say that this would be an useless listbox because it is a listbox and not a true tree, this is an intractable list when you have several project folders and some times the folders has the same name.

Searching for an easy solution I think that I could accept this assumptions:
- Only managers can move tasks and they are advanced users that could manage this intractable listboxs with every project folder for move action.
- Normal users only can manage tractable listbox for the 'jump by alias' action.

Then I should propose to put two checkbox where now there is the 'project' one:
- Autoalias checkbox (this is like the actual project checkbox but with a more clear name): All tasks of category with the autoalias checkbox enabled are showed in the 'jump by alias' listbox.
- Move-destination (this is for move action listbox): All tasks of category with the move-destination checkbox enabled are showed like a valid new parent in move task actions.

Thanks

[admin]

Hello,

I have a problem with moving tasks: I like to move tasks but I only can move tasks to 'project' tasks.

Yes, I agree, but we can implement it only in 3.0, 2.8 release should be available soon.

[victor]

Hello,

I have a problem with moving tasks: I like to move tasks but I only can move tasks to 'project' tasks.

Yes, I agree, but we can implement it only in 3.0, 2.8 release should be available soon.

Ok, I understand... I have another suggestion. Actually with TrackStudio 2.8 every task has an Id number (#). What about a raw move system where the user give the new parent id number?

Ha, ha, I know, I know what are you thinking about me at this moment ;)

[admin]

Hello,

I have a problem with moving tasks: I like to move tasks but I only can move tasks to 'project' tasks.

Yes, I agree, but we can implement it only in 3.0, 2.8 release should be available soon.

Ok, I understand... I have another suggestion. Actually with TrackStudio 2.8 every task has an Id number (#). What about a raw move system where the user give the new parent id number?

Ha, ha, I know, I know what are you thinking about me at this moment

You are not guess, I am really think "What do you mean ?"

Or you speaking about dynamic numbers like as 1.2.5.34 ?

[mvasenkov]

I say that this would be an useless listbox because it is a listbox and not a true tree, this is an intractable list when you have several project folders and some times the folders has the same name.

Hmm, Max, we can display this listbox as a tree.

[victor]

I say that this would be an useless listbox because it is a listbox and not a true tree, this is an intractable list when you have several project folders and some times the folders has the same name.

Hmm, Max, we can display this listbox as a tree.

Yes, this will be a good solution, maybe showing a full tree for move tasks action and only the 'project' tasks for jump action.

But I have supposed that this was not an easy solution (maybe there is not a tree control available now), but yes, I think that this would be the standard solution.

About the Id suggestion I was thinking about use the new task number (the task-# field). Then before move the user could see the parent task number (task-#) go to the task to move and write the wanted parent task-# in the parent task field.

I know that this is not a pretty solution but this is maybe the most easy and isolated solution to implement, this dont affect to the remainder code.

More clear now?

Maybe I appear a bit insistent about this but I am going to put some folders to receive tasks that after the manager has move to another folder and I have a problem with it. Actually I have two categories 'project' and 'subproject' (the first with the project attribute enabled) and when I want to move a task to a subproject I have to change the category of this task temporaly to do it :( ... It is a very poor solution but I cant full the jump list with all the projects/subprojects maybe if it was a tree I shall do, but I really accept any solution like use the task-#.

Thanks

[admin]

Hmm, Max, we can display this listbox as a tree.

Yes, this will be a good solution, maybe showing a full tree for move tasks action and only the 'project' tasks for jump action.

But I have supposed that this was not an easy solution (maybe there is not a tree control available now), but yes, I think that this would be the standard solution.

Yes, I remeber your suggestion about tree, but this solution cause some questions/problems: What tasks we should show in the tree ? Only "project" or all ? If we show only "project" - how we can display Project->SubTask->SubSubProject hierarchy ? If we show all - it should be very large page and we need some to load it on demand. If we load it on demand - how we should process when somebody move parent task when we move child ?
Also we should think how to move users - they has neither ID, nor "is project" property.

About the Id suggestion I was thinking about use the new task number (the task-# field). Then before move the user could see the parent task number (task-#) go to the task to move and write the wanted parent task-# in the parent task field.

I know that this is not a pretty solution but this is maybe the most easy and isolated solution to implement, this dont affect to the remainder code.

More clear now?

Maybe I appear a bit insistent about this but I am going to put some folders to receive tasks that after the manager has move to another folder and I have a problem with it. Actually I have two categories 'project' and 'subproject' (the first with the project attribute enabled) and when I want to move a task to a subproject I have to change the category of this task temporaly to do it ... It is a very poor solution but I cant full the jump list with all the projects/subprojects maybe if it was a tree I shall do, but I really accept any solution like use the task-#.

Thanks

Yes, this is not very good solution because user can enter incorrect task # and its difficult to understand it before submit - we need to get list of all available parent tasks # and check it in javascript before submit. Another problem - parent for users.

I think that we'll implement two checkbox as you describe early in the next version, it should be most proper solution.

By the way, why you can't assign unique alias for your subproject and enable "is project" for them ? In 2.8 you can jump to project by enter its name in "Task #" field, so you can ignore "jump to project" dropdown if it too large for you.

[victor]

I think that we'll implement two checkbox as you describe early in the next version, it should be most proper solution.

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.

By the way, why you can't assign unique alias for your subproject and enable "is project" for them ? In 2.8 you can jump to project by enter its name in "Task #" field, so you can ignore "jump to project" dropdown if it too large for you.

We have many projects with the same name but installed in different customers and we dont like to use innecesary fuuull names for project folders (a project folder named 'customer-product' inside the customer folder named 'customer').

I can ignore the 'jump to' list but pitifully I cant hidden it and it was a good hot-list.

Really I think that finally I am going to define every thing with the project attribute enabled and ignore the listbox in the 'jump to' box using this box only for put taks ids. Then when 3.0 was released I recover the 'jump to' box.

This is not a hard problem only an initially not expected concession to the actual application state... If some one has a better suggestion I am ready to learn.

Thanks!

[admin]

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

[admin]

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 ?