Support Forum

[victor]

Hello,

One doubt:

I am using TS 2.7.6 and the handlers combolist in message creation is not shorted. This is a bug or it is that this fix was done in TS 2.8?

Thanks

[admin]

I am using TS 2.7.6 and the handlers combolist in message creation is not shorted. This is a bug or it is that this fix was done in TS 2.8?

In 2.8 it still "partially sorted", it add sorted list of users that has access to root task, then sorted list of user that has access to the child and so on.

OK, we'll fix it in 2.8

[victor]

I am using TS 2.7.6 and the handlers combolist in message creation is not shorted. This is a bug or it is that this fix was done in TS 2.8?

In 2.8 it still "partially sorted", it add sorted list of users that has access to root task, then sorted list of user that has access to the child and so on.

Ok, I suspect that it was the problem...

OK, we'll fix it in 2.8

Thanks, with only a role by user I have long handlers list and I need that the list had been shorted.

[admin]

OK, we'll fix it in 2.8

Thanks, with only a role by user I have long handlers list and I need that the list had been shorted.

You means that you have many users with names like "John Smith, manager", "John Smith, developer", etc ?

Sorry, I hope that we'll fix this issue in 3.0

[victor]

OK, we'll fix it in 2.8

Thanks, with only a role by user I have long handlers list and I need that the list had been shorted.

You means that you have many users with names like "John Smith, manager", "John Smith, developer", etc ?

Sorry, I hope that we'll fix this issue in 3.0

No, I could do it, define more than one account by user (one by role), but I prefer avoid this.

I had prefered define that various roles are allowed in determined state.

For example:
1) I have two roles: Developer and Tester.
2) Developer is the central role in the state Developing. (Central role is the role that basically manage all messages in this state)
3) Tester is the central role in the state Testing.
4) I have a user named A and projects X,Y,Z.
5) User A has Developer role in projects X and Y.
6) User A has Tester role in projects Y and Z (he does per peer revisions).
7) Ideally I could define that A is:
- Developer in project X
- Developer and Tester in project Y
- Tester in project Z
8) But I cant do it. Then I could take two alternative solutions:
9a) Define two users: A-developer and A-tester and give the next ACL:
- Allow access to A-developer in project X
- Allow access to A-developer and A-tester in project Y
- Allow access to A-tester in project Z
9b) I coud define Developer like central role in Testing too.

The first solution (9a) is good for the system but bad for the user because the user must manage two (or more) accounts.
The second solution (9b) is bad for the system but good for the user because the system offer handlers that really cant accept the transition (for example: A could be tester but maybe could not be, or A is tester but B is developer too but not tester never).

I prefer the second solution this is not ideal but actually users know who is going to do every task and I only need that the list will be shorted.

Really I need it for this question but I think that it is a necesary fix because the handlers list must be shorted.

I hope that we can solve this multirole problem in the next (3.0) version... maybe before Christmas? I know that this is not 'simply a fix' and now I only expect to have the handlers list shorted.

Thanks

[admin]

I had prefered define that various roles are allowed in determined state.

For example:
1) I have two roles: Developer and Tester.
2) Developer is the central role in the state Developing. (Central role is the role that basically manage all messages in this state)
3) Tester is the central role in the state Testing.
4) I have a user named A and projects X,Y,Z.
5) User A has Developer role in projects X and Y.
6) User A has Tester role in projects Y and Z (he does per peer revisions).
7) Ideally I could define that A is:
- Developer in project X
- Developer and Tester in project Y

So, its important to you to allow multiple roles per project ? We plan to allow define role for project when you add user to Access Control list.

I hope that we can solve this multirole problem in the next (3.0) version... maybe before Christmas? I know that this is not 'simply a fix' and now I only expect to have the handlers list shorted.

OK, I understand. I has no ideas when we release 3.0, possible even in 2004. We going to release versions less often, but release more stable versions.

[victor]

So, its important to you to allow multiple roles per project ? We plan to allow define role for project when you add user to Access Control list.

Actually I have assumed a partial (but not full) directed handler selection: the system show possible handlers for each transition, but the list include some not expected handlers (right handlers but not expected by the user).

If you are thinking about do this per project role I could suggest you that you allow more than one role by user/project. (In my example user A was a Developer & Tester in a project)....

Maybe I could explode the roles and define something like 'Dev&Tester' and include this in my workflow, this would be interesting but in the per peer revisions generaly every one could be a peer... no problem I love the actual system and only need a completely shorted handlers list, hahaha ;) (this is not a joke, this is my real and realistic decision).

OK, I understand. I has no ideas when we release 3.0, possible even in 2004. We going to release versions less often, but release more stable versions.

Ok, this reafirm my decision, I really need a full shorted list, that's all.

Thanks

[admin]

Ok, this reafirm my decision, I really need a full shorted list, that's all.

If you need sorted list - we'll implement it in 2.8 beta (next week).