Support Forum

[victor]

Hi!,

I commented it in another topic but now I want to explicitly mark this limitation:

When I define a filter and I like talk about other users (like handler or submitter) I cant talk about users that have not access to the actual active task.

Then if I like to define a global filter (for every task) for tasks submitter by for example 'peter, john and marcus (three specific salesmen)' but they only have access to some specific subtasks then I cant define it globally because I can't select them from the listbox.

I think that a more powerfull solution could be that a user could select every user that is hanging over the subtree defined by his parent user including his parent.

Example:
I use the next syntax to define a subtree:
node(childnode1,childnode2,...,childnodeN)

a(b(d,e(k,l),f(m,n),g),c(h,i,j))

- b can view every user down his parent (a) (that is: all users)
- d can view every user down his parent (b) (that is: b,e,f,g,k,l,m,n)
- k can view every user down his parent (e) (that is: e,k,l)
- i can view every user down his parent (c) (that is: c,h,i,j)

Thanks

[victor]

Hello,

I think that I have a solution that is right and that only require modify the logic to fill the handler/submitter lists.

Now I suspect that these lists of users are filled with the users that have access to the actual project.

If this supposition is right we could have a more powerfull system if these lists of users was filled with the users that have visibility of the actual project.

When visibility I mean that the lists could be filled with the users that have access to the actual project or any project inside it.

This logic is the same that actually TS is using to decide if a user can view or not a subtask in the subtasks list: a user can view all subtasks where he has access or where there is a subtask that he can view (recursive definition).

What about it?

Thanks!

[admin]

Hi!,

I commented it in another topic but now I want to explicitly mark this limitation:

When I define a filter and I like talk about other users (like handler or submitter) I cant talk about users that have not access to the actual active task.

Then if I like to define a global filter (for every task) for tasks submitter by for example 'peter, john and marcus (three specific salesmen)' but they only have access to some specific subtasks then I cant define it globally because I can't select them from the listbox.

I think that a more powerfull solution could be that a user could select every user that is hanging over the subtree defined by his parent user including his parent.

Example:
I use the next syntax to define a subtree:
node(childnode1,childnode2,...,childnodeN)

a(b(d,e(k,l),f(m,n),g),c(h,i,j))

- b can view every user down his parent (a) (that is: all users)
- d can view every user down his parent (b) (that is: b,e,f,g,k,l,m,n)
- k can view every user down his parent (e) (that is: e,k,l)
- i can view every user down his parent (c) (that is: c,h,i,j)

Thanks

I understand you logic and I know about this limitation, but imagine what happen with our hosted service - every new user will see all users down his parent (root user) - all users in systems. This is security problem and perfomance problem - just imagine loading list of 1500 users.

[victor]

I understand you logic and I know about this limitation, but imagine what happen with our hosted service - every new user will see all users down his parent (root user) - all users in systems. This is security problem and perfomance problem - just imagine loading list of 1500 users.

Yea!, I think that the first idea was a bad one... Read the second proposal about use visibility and not accesibility...

[admin]

Hello,

I think that I have a solution that is right and that only require modify the logic to fill the handler/submitter lists.

Now I suspect that these lists of users are filled with the users that have access to the actual project.

If this supposition is right we could have a more powerfull system if these lists of users was filled with the users that have visibility of the actual project.

When visibility I mean that the lists could be filled with the users that have access to the actual project or any project inside it.

This logic is the same that actually TS is using to decide if a user can view or not a subtask in the subtasks list: a user can view all subtasks where he has access or where there is a subtask that he can view (recursive definition).

What about it?

Thanks!

Sorry, but we also can't. On large databases this means that we should check every user and every project and check that user have visibility of actual project. In such situation we should store all users and tasks in memory - this can cause major perfomance problems (like we have with 2.7 and hosted service).

So, this fix require cache improvement (that already have 4(!) layers and quite smart and comprehensive) and this is major fix for us. Possible, we'll resolve this in 3.0, but not sure yet.

[victor]

Sorry, but we also can't. On large databases this means that we should check every user and every project and check that user have visibility of actual project. In such situation we should store all users and tasks in memory - this can cause major perfomance problems (like we have with 2.7 and hosted service).

So, this fix require cache improvement (that already have 4(!) layers and quite smart and comprehensive) and this is major fix for us. Possible, we'll resolve this in 3.0, but not sure yet.

I shouldn't like be insistent, I understand the performance problems and about this specific question (the filters I am refering) I think that we could see this improvement from this point of view:

a- We can have not this improvement.
b- We can have it like an optional thing with a slow performance.
c- We can have it like a good fast improvement.

Now we are in state a but for the users that like it they will prefer to be in state b or better in c.

What about put it like an optional improvement. The system run like now but you put a button to change from an access users list to an visibility user list.

This is only an idea, an intermediate state to the final solution.