Support Forum

[victor]

Hello,

I have a enterprise installation for an alone company. All users have the Admin like parent manager.

Yesterday a group leader ask me about how can he view the tasks of all his group.

Actually I think two solutions:
1) the leader can create a filter with multiple selected handlers.
2) I could do the leader to be the parent manager of all his group users and then define a filter with 'I and my subordinateds" like selected handlers.

But with one and other solution I have some problems.

Problems:

1) The leader can create a filter with multiple selected handlers

If we try to create a filter for (my group handlers) in the root (project task) We only can select users that have access to this project.

This could be right if we were defining a non recursive filter, but we are defining a recursive one. In this case the leader must can select every user with access in some subtask. Or more easly: the leader must can select every user that is under the same parent manager that him.

Then this is not a valid solution because it suppose that the user must define the same filter in every subtask.

2) I could do the leader to be the parent manager of all his group users and then define a filter with 'I and my subordinateds" like selected handlers

I have moved all the group users to have this leader like their parent manager. But now I cant define that the leader can change his user data but not the subordinated users data.

I think that status must have rights for the users data and for subusers data. For example: The leader must can change his password but not his subusers passwords, and the same with the users data (email, etc)...

For last one question:

If I change my lineal users structure (every user has Admin like parent manager and change to a tree hierarchy what differences I (and the users) am going to experiment?

Thanks

Victor

[mvasenkov]

The leader can create a filter with multiple selected handlers
You (Admin) can create a user status (group) like 'grouped-user' and change status for all users in group. Then group leader can create a filter with conditions like 'handler status is 'grouped-user'' or 'submitter status is 'grouped-user''.

[victor]

The leader can create a filter with multiple selected handlers
You (Admin) can create a user status (group) like 'grouped-user' and change status for all users in group. Then group leader can create a filter with conditions like 'handler status is 'grouped-user'' or 'submitter status is 'grouped-user''.

Interesting point of view, but I have a problem... actually by workflow needs I have to give different status to different users, that is, I have that a leader has two developers and one tester in his team.

I think that with this need I cant use your solution, can I?

Thanks

___________________________
Changes are 'everything'

[admin]

The leader can create a filter with multiple selected handlers
You (Admin) can create a user status (group) like 'grouped-user' and change status for all users in group. Then group leader can create a filter with conditions like 'handler status is 'grouped-user'' or 'submitter status is 'grouped-user''.

Interesting point of view, but I have a problem... actually by workflow needs I have to give different status to different users, that is, I have that a leader has two developers and one tester in his team.

I think that with this need I cant use your solution, can I?

Thanks

Yes, I agree, this complex your workflow (already quite complex, I think) too much.

Another solution - revoke USER_LIST, USER_CREATE and USER_DELETE roles from your managers. In such case manager can access subordinated users, but can't view/edit/delete them.

[victor]

Another solution - revoke USER_LIST, USER_CREATE and USER_DELETE roles from your managers. In such case manager can access subordinated users, but can't view/edit/delete them.

I try some variants in the USER level:
- NONE : I can view subordinated users list and go to subordinated data link. I cant view my data.
- USER_LIST : Like none but I have a LIST link.
- USER_MODIFY : Like none but now I can change subordinated data, include I can give administrator status to they!. (I cant view my data).
- USER_VIEW : Initially I can view subordinated list and data (without LIST link, only using my user link) and I can view my data. I cant change nothing.
- USER_MODIFY & USER_VIEW: Like USER_VIEW but I can modify.

I want:
- Can modify my data
- Cant modify my subordinated data (specially I want that some one can give admistrator role to a subordinated user).

Optionally I want too:
- Can view my subordinate list
- Can view my subordinate data

Thanks,

[admin]

Another solution - revoke USER_LIST, USER_CREATE and USER_DELETE roles from your managers. In such case manager can access subordinated users, but can't view/edit/delete them.

I try some variants in the USER level:
- NONE : I can view subordinated users list and go to subordinated data link. I cant view my data.
- USER_LIST : Like none but I have a LIST link.
- USER_MODIFY : Like none but now I can change subordinated data, include I can give administrator status to they!. (I cant view my data).
- USER_VIEW : Initially I can view subordinated list and data (without LIST link, only using my user link) and I can view my data. I cant change nothing.
- USER_MODIFY & USER_VIEW: Like USER_VIEW but I can modify.

I want:
- Can modify my data
- Cant modify my subordinated data (specially I want that some one can give admistrator role to a subordinated user).

Optionally I want too:
- Can view my subordinate list
- Can view my subordinate data

Thanks,

OK, but I need to think. Now we rewrite security subsystem (to support SOAP or more flexible object model in calculated custom fields, for example), I'll take your suggestions in account.

[victor]

I understand that a complete solution where we can define rights for users and subordinates is complex to implement and need new fields.

But I see that the actual implementation is wrong because I have only two solutions:

1) Give to the user rights to modify his data and his subordinateds data.
2) Deny rights to the user to modify his data and his subordinateds data.

With solution 1 there is a security lack because a user can give administrator status to a subordinate.

With solution 2 a user can't change modify his own data (for example his email or password) and this is a very restrictive action.

I propose you to change the actual implementation without have to add fields in the data base.

These are the premises:

a. An user can view his data.
b. An user can modify his data and password.
c. USER_LIST allow user see the subordinateds list (never, not like now).
d. USER_VIEW allow user go to subordinated data sheet and view it (USER_LIST right could be required)
e. USER_MODIFY allow like d but the user can modify suborditated data too (USER_LIST and USER_VIEW rights could be required)
f. USER_PASSWORD allow user go to subordinated change password data sheet and modify it (USER_LIST, USER_VIEW and USER_MODIFY rights could be required)
g. Never an user can change his role.

That's all.

I know that this dont change the database requeriments but that this is not trivial to do... but now the alternatives are very poor ones (IMHO).

Thanks

[victor]

Like you know before use the users hierarchy I was using a users list (all with root like parent).

In this conditions I didn't need a right hierarchy users rights solution.

I am the TS administrator in my company and then I am between the company users needs and the TrackStudio programers restrictions (logic restrictions because we can reimplement everything in every moment was the reimplementation by bugs or by 'fantastic' improvements).

Over this point of view I cant lost the aim because I desire for you a more near to the perfection TrackStudio but after all I want a solution to reach the users aims.

Then?... Well actually my users dont need a users hierarchy they want know the status of all the tasks over their projects.

This is:
- If user-A (project leader) have assigned project-1, project-4 and project-7 he want a list with all the tasks that are opened in this three projects.
- And if user-B (project leader) have assigned project-3 and project-6 he want a list with all the tasks that are opened in this two projects.
-Each project can have different users some ones subordinateds to the project leader, some ones subordinateds to other leaders.

This mean that the users hierarchy cant solve this users aim. And then I want a solution to the hierarchy bug, but not necessarily now because with it I solve only partially the aim, but a partial solution for this aim is not a good solution.

I am sorry all the headaches, I have to think more to find a more complete solution and actually I dont know if I am going to need the users hierarchy or not... I think that I am not to need it then I think that is better that you relegate this complex bug a time.

Thanks,

[vpantiru]

Hi,
Is it possible to resend the password if a regular user has forgotten it?

[victor]

Hi,
Is it possible to resend the password if a regular user has forgotten it?

I suppose that basically the administrator must reset the user password to a temporal one and send it to the user asking him to change it the first time that he login.