# Improving Project Permisions

**URL:** https://discuss.tryton.org/t/improving-project-permisions/140
**Category:** Feature
**Tags:** project
**Created:** [June 14, 2016, 2:43pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140 "2016-06-14T14:43:42Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [June 14, 2016, 2:43pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/1 "2016-06-14T14:43:42Z")

</div>

Currently we have only one permision related to the project module, which gives a all permissions to the project module. Other users on the system have readonly full access to projects. So I see two drawbacks here:

1. There are users on the system that must not access the project info, for example the current projects is not relevant to the accountant.
2. There is no project user, which is only allowed to work on the existing tasks.

It will be great if we add a new “Project Group” which the following permissions:

- Only users of this group can access the “Project Menu”
- Users of this group can read and modify existing projects/tasks but can not create or delete them.

Comments and opinions are very welcome.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 14, 2016, 2:51pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/2 "2016-06-14T14:51:48Z")

</div>

> [@pokoli](#):
>
> There are users on the system that must not access the project info, for example the current projects is not relevant to the accountant.

I don’t see any issue here. Projects are not critical information that should be hidden.  
But of course, some field could be sensible but in that case it is a customization of the field access.

> [@pokoli](#):
>
> There is no project user, which is only allowed to work on the existing tasks.

I’m not sure to understand what you mean. Encoding time-sheet does not require any access right on the project.

> [@pokoli](#):
>
> Users of this group can read and modify existing projects/tasks but can not modify it.

For me, this sentence contains contradictions.

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [June 14, 2016, 2:59pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/3 "2016-06-14T14:59:33Z")

</div>

[quote="ced, post:2, topic:140]

> [@pokoli](#):
>
> There are users on the system that must not access the project info, for example the current projects is not relevant to the accountant.

I don’t see any issue here. Projects are not critical information that should be hidden.  
But of course, some field could be sensible but in that case it is a customization of the field access.  
[/quote]  
Maybe we can provide a good defaults for this. .

[quote="ced, post:2, topic:140]

> [@pokoli](#):
>
> There is no project user, which is only allowed to work on the existing tasks.

I’m not sure to understand what you mean. Encoding time-sheet does not require any access right on the project.  
[/quote]

For me working in the task means more than encoding timesheet, for example:

- Describing what have been done in the description.
- Marking the task as done

But also means:

- Not being able to modify task planification.

[quote="ced, post:2, topic:140]

> [@pokoli](#):
>
> Users of this group can read and modify existing projects/tasks but can not modify it.

For me, this sentence contains contradictions.  
[/quote]  
Right, i mean, can read and modify, but not create or delete tasks/projects.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 14, 2016, 3:10pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/4 "2016-06-14T15:10:47Z")

</div>

> [@pokoli](#):
>
> Describing what have been done in the description.

This should probably use the “Note” feature and so it doesn’t require write access on the record.

> [@pokoli](#):
>
> Marking the task as done

I think this should be done with buttons. And with [issue5010](https://bugs.tryton.org/issue5010), such button could not require write access.  
But the difficulties is that there is no obvious work-flow for project/task, so maybe just displaying all available states as button is good enough.

> [@pokoli](#):
>
> Right, i mean, can read and modify, but not create or delete tasks/projects.

I think it will be a mistake to give write access by default. Indeed I think we should avoid to have the need to write access by using other Models like timesheet, buttons or wizards.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 14, 2016, 7:06pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/5 "2016-06-14T19:06:41Z")

</div>

One more thoughts, I think we could have a new module that allow to configure access rights per project/task. It could be a list of users for each accesses that are inherited by default from the parent. This could be managed with the record rules.

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [June 15, 2016, 3:37pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/6 "2016-06-15T15:37:20Z")

</div>

> [@ced](#):
>
> > [@pokoli](#):
> >
> > Describing what have been done in the description.
> 
> This should probably use the “Note” feature and so it doesn’t require write access on the record.

Just for future reference, this is not correct. The note feature requires create access on the model to create notes, and write access on the model to edit notes.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [June 15, 2016, 3:46pm UTC](https://discuss.tryton.org/t/improving-project-permisions/140/7 "2016-06-15T15:46:01Z")

</div>

This should probably be improved by the new module I described.  
So it could have a list of user who has the right to add notes/attachment.

---

<div class="post-metadata">

### Author: ![ptarra](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ptarra/32/297_2.png) [@ptarra](https://discuss.tryton.org/u/ptarra)
#### Post date: [January 23, 2020, 8:23am UTC](https://discuss.tryton.org/t/improving-project-permisions/140/8 "2020-01-23T08:23:34Z")

</div>

Does this module exist? I can’t seem to find it anywhere

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [January 23, 2020, 8:37am UTC](https://discuss.tryton.org/t/improving-project-permisions/140/9 "2020-01-23T08:37:16Z")

</div>

Hi Pedro, this feature is not yet implemented, so it’s normall that you did non find it anywhere.

But it will be great to extend this topic with your needs to see if there is something that can be improved.

---

<div class="post-metadata">

### Author: ![ptarra](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ptarra/32/297_2.png) [@ptarra](https://discuss.tryton.org/u/ptarra)
#### Post date: [January 23, 2020, 8:59am UTC](https://discuss.tryton.org/t/improving-project-permisions/140/10 "2020-01-23T08:59:26Z")

</div>

Not much. We are going to use the project module to keep track of some internal projects that affect different areas and personel. Most of the users in the organization will be involved in at least one project (so almost all the users should have access granted to project/tasks) but most of them will just be interested in their own tasks and subprojects. Being able to limit the access rights would be nice.
