PDA

View Full Version : managing permissions


anjin
08-11-05, 08:34 PM
Hi Everyone,

I just wanted to know can i configure dotproject. So that i has a three
architecture. What i meant by this is :- If i create a client , then the client
gets the privilege to create company and project and users for that company. But
the users created by my client can't access each others information.

Thanks in advance who can help me
Anjin Pradhan

MacOfTheEast
08-11-05, 11:00 PM
I just wanted to know can i configure dotproject. So that i has a three architecture. What i meant by this is :- If i create a client , then the client gets the privilege to create company and project and users for that company. But the users created by my client can't access each others information.

It's like deja vu! I could swear I read this yesterday... AND I'M SOBER, TOO! :-)

See here for yesterday's reply.

http://www.dotproject.net/vbulletin/showthread.php?t=3864&highlight=anjin

alleyCat
09-11-05, 08:37 AM
twilight zone!

jleone
13-11-05, 07:05 AM
I found the following roles/permissions settings allowed me to create a read-only view on a given company's set of projects--and only those projects--for a given client associated with the company in question:

Role Settings:
Item: Projects
Type: Access, View
Status: Allow

Item: Tasks
Type: View
Status: Allow

User-Level Permissions:
Type: Companies
Item: Access
Status: Deny

Type: [the Company in question]
Item: Access, View
Status: Allow

Cheers,

janvrot
27-11-05, 01:14 PM
However there is a hole in that setup.

With the url http://my.server/dotproject/index.php?m=tasks&a=view&task_id=X
the user has view access to *any* task from any project/company, by just using the corresponding X, not beeing restricted to the projects' companies' tasks.

I don know how to avoid that.

If you use instead the url http://my.server/dotproject/index.php?m=projects&a=view&project_id=X
just the expected Xs allow access, as it should. For others you get an "Access denied".

It seems that task-project dependency is not checked in this case.

Cheers
Janvrot

janvrot
27-11-05, 03:34 PM
Otherwise anyone who creates a task should set it's type as protected, participant or private (public is the default and as stated somewere in the forums, anywone may access a public task).

Perhaps there is a missing functionality here. It seems reasonable to me let an user that has access to a project to access it's tasks as a default, speccialy in the case of supervisors and managers not allocated to the task.

However, as of my understanding (forums):
For a protected task the user should be the the owner or a task participant who is from the same company as the owner.
For a participant task the user should be a participant, not necessarily from the same company the owner is.
For a private task only the owner has access.

To allocate a manager all the tasks for all projects under her hierarchy would be a mess. Someone could simply forget do do so, and also all those tasks would appear in the manager's ToDo list. To let such a guy be a sys adm maybe is not a good idea ;)

Did I get it right? Any ideas?

Janvrot