Support Forum

[victor]

Hello,

Recently I enabled the 'Can modify ACL' to the managers, before only the administrator can do it.

Now managers can see the ACL section in tasks.

I found that one manager that has child users can change only permission to his childs. This sounds fine but not completely fine (only half fine).

For example this is fine if you are thinking that a task is a project that has a Development Leader and this leader has like childs to every developer implicated in this project.

But this is not so easy if you think that in a project not only the development team is involved . For example some members of the testing group could be involved and maybe a developer from another development team.

This testers and foreign developer need that someone give access to the project, but if the project leader cant give this access and need to call to the administrator all this ACL structured system is broken.

I think that really the leader of a project must be the handler of this task. And then this leader must be allowed to give or deny access to every brother or brother-childs.

I know that this is a problem for the hosted use of trackstudio and that a system to limit to a subtree the users accesibles would be need but if we dont have this evidently the ACL and some filter characteristics (I sent you a topic about it some time ago) are completely unuseful for us.

Another curiosity about this is that a user with ACL can see him, his childs and others users that have 'Inherited from parent task' access but this user cant see other users (brothers) with access defined in this task level.

Thanks

[admin]

Hello,

Recently I enabled the 'Can modify ACL' to the managers, before only the administrator can do it.

Now managers can see the ACL section in tasks.

I found that one manager that has child users can change only permission to his childs. This sounds fine but not completely fine (only half fine).

For example this is fine if you are thinking that a task is a project that has a Development Leader and this leader has like childs to every developer implicated in this project.

But this is not so easy if you think that in a project not only the development team is involved . For example some members of the testing group could be involved and maybe a developer from another development team.

This testers and foreign developer need that someone give access to the project, but if the project leader cant give this access and need to call to the administrator all this ACL structured system is broken.

I think that really the leader of a project must be the handler of this task. And then this leader must be allowed to give or deny access to every brother or brother-childs.

Possible, matrix help you.
For example, you define hierarchical structure of users: root->manager of department(R&D, QA, PM, etc)->member of department.
Managers of department have access control to the root task, odinary users (even project managers) has no such permissions.
When project manager need some developer or tester - he simple ask department manager and (if he agree) - he add user to the project.

Now project managers can use users from different departments and department managers can gather statistics about members of their department.

I'll put some sample now, let me a minute...

[admin]

Hello,
This testers and foreign developer need that someone give access to the project, but if the project leader cant give this access and need to call to the administrator all this ACL structured system is broken.

Please download
http://www.trackstudio.com/tse-28/sample_matrix.zip

This is HSQL database in TrackStudio 2.8 format. Please login as root/root and investigate the structure. All passwords are equals to logins.

Let me know if you have any questions.

PS. You can even define special workflow for "please assign developer to the project" request.

[victor]

Your solution is a good solution but introduce us to a set of problems:

- We dont use TrackStudio like a human resources administration tool. We use the MS-Project resources pool and meeting between group leaders and the projects manager. But I think that your workflow solution about ask users to another group leader is a good improvement to the company workflows.

- We have a more hard problem with your solution. Our group leaders (or group managers) are project leaders too. If I give access over the main task to these group managers then I convert their in potential handlers in all our projects and this is irreal. Now, when I am writing this I think that this could be solved If we could define multiple roles for each user in each project.... Then we could give access over the main task to the group managers with the group-manager role (not involved in projects workflows) and after give their access over specific projects with the project-leader role.

Maybe then this could be a really good solution because truly the model that you has presented is a more real model but for it we need can define multiple role for each user in each project. I am talking about it for 7 months a go and I dont know if you are going to incorporate it to TrackStudio in version 3.0 and when is going to be released it.

[admin]

Maybe then this could be a really good solution because truly the model that you has presented is a more real model but for it we need can define multiple role for each user in each project. I am talking about it for 7 months a go and I dont know if you are going to incorporate it to TrackStudio in version 3.0 and when is going to be released it.

This feature already in progress and will be included in 3.0. I hope that we'll release 2.8 in the March.

[victor]

Maybe then this could be a really good solution because truly the model that you has presented is a more real model but for it we need can define multiple role for each user in each project. I am talking about it for 7 months a go and I dont know if you are going to incorporate it to TrackStudio in version 3.0 and when is going to be released it.

This feature already in progress and will be included in 3.0. I hope that we'll release 2.8 in the March.

Fine... I suspect that when you said release 2.8 in the March you want to say release 3.0, it's ok?

[admin]

Fine... I suspect that when you said release 2.8 in the March you want to say release 3.0, it's ok?

Yes, 3.0.

It should be largest TrackStudio release, primary because external integration. Most systems offer some king of Open API, that contains classes that can be used to talk with system. In TrackStudio we has been opened kernel of the system as SOAP API. This means that JSP on the application server and external software can use the same API, this allows very good and simple integration with other systems.
But this is difficult task - because now anybody can use kernel - we need to make it secure. We also need to rework most objects to make it SOAP-complaint.

But now most of those tasks done and I hope that we'll release 3.0 in a time.

[victor]

Fine... I suspect that when you said release 2.8 in the March you want to say release 3.0, it's ok?

Yes, 3.0.

It should be largest TrackStudio release, primary because external integration. Most systems offer some king of Open API, that contains classes that can be used to talk with system. In TrackStudio we has been opened kernel of the system as SOAP API. This means that JSP on the application server and external software can use the same API, this allows very good and simple integration with other systems.
But this is difficult task - because now anybody can use kernel - we need to make it secure. We also need to rework most objects to make it SOAP-complaint.

But now most of those tasks done and I hope that we'll release 3.0 in a time.

Fine, congratulations. I confess that I dont know nothing about the SOAP API and I saw it like an enemy for my propossed improvements because SOAP substract worktime and possibilities to my improvements. Maybe the problem is that I dont know what kind of benefits could give me the SOAP API... my apologizes by my SOAP API reluctance ;)

Congratulations again. I know that March is a hard deadline to complain but I hope that you understand that we are anxious to use TS 3.0 :D

Thanks