Easy way to allow creation of 'own' tasks?

[Wendebaum]

I have the following problem to solve:

We have around 35 people working together on many projects. Projects are created and configured by a few project leaders who assign tasks to the developers. Now these developers should be allowed to create subtasks for all their tasks if they want to. Is this possible without going through each single tasks, looking up the assigned people and setting permissions for them?

Another question: Why do I have to set "allow project edit" to have people let create tasks. Shouldn't this be done via "allow tasks create"? What is that second permission for?

Thanks,
Jochen

[caseydk]

When you allow someone to create/edit tasks, you're really letting them modify the project too.

For example, someone with task-adding permissions could add tasks in a way to make the project completion appear lower than actual.

[Wendebaum]

so is there an easy way to let people edit "their" tasks including the creation of subtasks? I assumed that this new permission system included that feature...

[Wendebaum]

Well, no ideas?

[pedroa]

Hi,

I haven't tried the stuff I will be saying here (at least not all) but my knowledge of the permissions system gives me the believe that if you want to give permission to an item (a task in your example) then you must enforce (grant) that permission item by item. This means that in order to grant access/edit/etc to a task, you will then have to give it one by one to a user (and each and everyone of them).
Subtasks (better know in my opinion as normal tasks with a parent different than themselves) don't have a module of their own, or a permission separation from their parent task, so you can not adopt a way of doing what you want as you could with Projects / Tasks.
The idea is if the user was not able of creating the main task then he will not be able to create a subtask either (or any other task).
So the only way of doing this is one by one, by the admin (or project leader in your case).
The problem resides firstly on tasks and subtasks being to dP the same thing. The second problem is that you don't know when a task is to be created if it will be a subtask or not.
If you can solve the second problem, then the first can be hammered and resolved.

Pedro A.

[Wendebaum]

well, not completely...

I doesn't matter if a task is a main or a sub task. I want to allow users to add child tasks to all tasks that they are assigned to. This should be hackeable... *ponders*

[pedroa]

The problem resides firstly on tasks and subtasks being to dP the same thing. The second problem is that you don't know when a task is to be created if it will be a subtask or not.
If you can solve the second problem, then the first can be hammered and resolved.

Read the quote slowly...

I don't believe I misunderstood you, and depth of the task is not the problem (eventhough, it can be a variable, because you don't want assignees to add main tasks only subtasks). The real problem is determining how should the system know how to let or not let create the tasks.
There must be an objective way of distinguishing the tasks.
I am thinking about hacking:
One idea was to verify if the task_id is equal to the task_parent field, if so don't let the insertion of the task go trough for assignees only for PMs, if not let the insertion go on because we are creating a subtask.
Other idea would probably be to create a subtask module and manage the permissions within the system and not hack the SQLs (this of course would be harder).
Other was to verify if the user is an assignee, and only let him insert a task if he was creating a subtask to one of his assigned tasks.

By the way:
"Another question: Why do I have to set "allow project edit" to have people let create tasks. Shouldn't this be done via "allow tasks create"? What is that second permission for?"

You don't need to have "allow project edit", only "allow project access/view", alongside with "allow company access/view".
"allow tasks create" grants you the right to had tasks, yes it does but... to nothing if there is nothing (company, project) accessible/viewable. That's why you need the first.

Pedro A.

[Wendebaum]

When you create a task, you can specify a parent task. Creation of the new task should only be permitted if the parent task is assigned to me. So when I click "save task" the software could lookup the parent task, find out if I am assigned to it and if I am, it could create the task. If I am not assigned to the parent, it should bring up a message saying that I am not allowed.

So the "new task" button could be shown in the task view of a task that I am assigned to. When I click that button, the parent task field is filled automatically with the parent task.


To the second point: I have set
- non-admin: allow access, add, delete, edit, view
- companies: deny delete
- projects: deny add, delete

Is this the same as your described setup?

[pedroa]

Hi,

The non-admin modules also include the project and the company module, so you will have a confict of permissions there.
non-admin modules, all modules, admin modules are groups of modules defined in the permissions system so that you could affect the included modules in one grant.
If you see delete is in conflict because you are allowing it and then denying it for companies and also deny add for projects.
I don't know the result of this.

The best way of doing this is to know first what do you want the user to do and not do.

dP permissions are used in a not available at all if you don't have a permission so denying is most of the times not needed (I really don't use it).
Just grant what users are able to do.

So you want users to see the top menu for each module:
non-admin, allow, access

So you want users to see the content for each module:
non-admin, allow, view

So you want then both and also be able to edit each module item:
non-admin, allow, access view edit

They are able to add companies too:
company, allow, add

You end up with;
non-admin, allow, access view edit
company, allow, add

All the rest is denied.
Be aware that every item is available this way, and may need to grant add delete permissions to other modules like tasks, calendar, events...etc

I am not saying that your solution doesn't work, but be sure to try it and see if it works as you want, and if it does... Great.

I was just trying to show the other way round.

Pedro A.