project module: How to restrict the creation of a project, but not restrict task creation

[Udo Spallek]

Hi all,

the project module has the great conception that a project and a task
share the same model project.work. The difference between a project and
a task is that both are types of project.work. With this it is easily
possible to change overwhelming tasks into projects and stub projects
into tasks.

I have problems to solely restrict the access for project creation, but
allowing to add tasks. Which seems a usual case in project management.
The project manager should be able to create a project and add tasks,
but the project worker should be able to only add tasks to a project,
but not add new projects.

With res.groups I can only restrict coarse-grained model-wise: no
creation of projects _and_ no creation of tasks. Which means, Iam only
able to restrict the access to model project.work as a whole.

Ir.rule.group and ir.rule seem not the right place for this
restrictions, too. In ir.rule (aka 'Tests' on UI) I can not check for
the field 'type' on project.work, because the values in operand are
restricted to res.user[1].

Do you have an idea how to handle different access to project.work based
on the field type == 'project' and type == 'task'?

TIA

Regards Udo

[1] http://hg.tryton.org/trytond/file/tip/trytond/ir/rule.py#l138
--
Udo Spallek

------------------------------------
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle

Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Cédric Krier]

On 21/12/10 10:25 +0100, Udo Spallek wrote:
> Hi all,
>
> the project module has the great conception that a project and a task
> share the same model project.work. The difference between a project and
> a task is that both are types of project.work. With this it is easily
> possible to change overwhelming tasks into projects and stub projects
> into tasks.
>
> I have problems to solely restrict the access for project creation, but
> allowing to add tasks. Which seems a usual case in project management.
> The project manager should be able to create a project and add tasks,
> but the project worker should be able to only add tasks to a project,
> but not add new projects.
>
> With res.groups I can only restrict coarse-grained model-wise: no
> creation of projects _and_ no creation of tasks. Which means, Iam only
> able to restrict the access to model project.work as a whole.
>
> Ir.rule.group and ir.rule seem not the right place for this
> restrictions, too. In ir.rule (aka 'Tests' on UI) I can not check for
> the field 'type' on project.work, because the values in operand are
> restricted to res.user[1].
>
> Do you have an idea how to handle different access to project.work based
> on the field type == 'project' and type == 'task'?

Yes it should be done with rules but the interface is not enough powerful.
I think we should consider to drop the one2many list for a char field where we
could write any domain.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Cédric Krier]

On 21/12/10 10:25 +0100, Udo Spallek wrote:

> Hi all,
>
> the project module has the great conception that a project and a task
> share the same model project.work. The difference between a project and
> a task is that both are types of project.work. With this it is easily
> possible to change overwhelming tasks into projects and stub projects
> into tasks.
>
> I have problems to solely restrict the access for project creation, but
> allowing to add tasks. Which seems a usual case in project management.
> The project manager should be able to create a project and add tasks,
> but the project worker should be able to only add tasks to a project,
> but not add new projects.
>
> With res.groups I can only restrict coarse-grained model-wise: no
> creation of projects _and_ no creation of tasks. Which means, Iam only
> able to restrict the access to model project.work as a whole.
>
> Ir.rule.group and ir.rule seem not the right place for this
> restrictions, too. In ir.rule (aka 'Tests' on UI) I can not check for
> the field 'type' on project.work, because the values in operand are
> restricted to res.user[1].
>
> Do you have an idea how to handle different access to project.work based
> on the field type == 'project' and type == 'task'?
>

For the record, it seems that this patch allow to fix the issue:

http://codereview.appspot.com/3867043/