Support Forum

[andrew_bt2]

Dear Maxim,

I would like to know if there is a way to hide the "handler" field to the specific users who entered tasks or messages - We would like that because in our company, the assignment of the handler is not by the task creator (end user), it is by the project managers (default handler).

We would like to have the field completely hide from certain user group (end user). Is it possible?

Regards,

andrew

[admin]

Dear Maxim,

I would like to know if there is a way to hide the "handler" field to the specific users who entered tasks or messages - We would like that because in our company, the assignment of the handler is not by the task creator (end user), it is by the project managers (default handler).

We would like to have the field completely hide from certain user group (end user). Is it possible?

Regards,

andrew

The situation is slight more complex, I'll try to describe why:
when TrackStudio show you list of available handlers - it ensure that handler can move task from target state to another (or same) state. So, when you set user as handler - you can be sure that your current workflow allow that user to process it.

So, if in your team only manager can assign user after you create task -
you should create some start state (toassign, for example) and define in workflow rules that only manager can move task from 'toassign' state to process 'state'.

If you need that only manager can set tester after the developer resolve bug - you should create an additional state between "resolved" and "verified" with the the processing same rules.

We can't just disable hander field, because it can cause issues when
1) task have no handler, but it should have one in this state.
2) the current handler is incorrect, because it has been inherited from previous state and has no sense for the current state.

PS. About handler change policy at all - I found very useful when handler of the task can change handler. In our team users change handlers when he/she can't process task because he/she has questions or need more information. So, handler means "responsible for delay at this state", not user who responsible for task at all.
This can avoid situation when developer can't process task because
1) he/she has questions to manager
2) he/she can't change handler to manager and can only left comment.
3) manager can't easy find tasks with questions to him.

This problem especially important when you have several distributed teams.

[andrew_bt2]

Dear Maxim,

Thanks for your prompt reply! I total agree with the rationale behind current logic. However. I would like to know if an option can be added so that when creating tasks, the handler assignment is invisible to certain user in certain task? Also, the system should assign it to the default handler for this situation.

I think it is very useful for teams who are dealing with external clients - We do not want outsider client know who is available to handle the task.

Please consider my suggestion!

Thanks and regards,

andrew

[admin]

Dear Maxim,

Thanks for your prompt reply! I total agree with the rationale behind current logic. However. I would like to know if an option can be added so that when creating tasks, the handler assignment is invisible to certain user in certain task? Also, the system should assign it to the default handler for this situation.

I think it is very useful for teams who are dealing with external clients - We do not want outsider client know who is available to handle the task.

Please consider my suggestion!

Thanks and regards,

andrew

Yes, in previous version users can't change handler when he/she add bug, but we change this in 2.8:
http://trackstudio.com/forum/viewtopic.php?t=137

I think that solution is more global - we need configurable field-level security, we'll implement it in one of the future versions (3.0, possible).

Right now I suggest you create additional project for each your external user (you can also do it automatically with "External user self-registration" feature) and after user create bug and you decide that you'll resolve it - just move it to different project, resolve, and move it back. You developers shouldn't have access rights to user's project and user can't change handler.

Just another small note - as you can see, our customers has no access to TrackStudio and can't add/view bugs directly. Instead, I add such suggestions to some subproject manually, if we can implement it in the near future. The logic behind this is the following:
1) Too direct connection between customers and developers is bad idea, fixing many small issues very easy to lost strategic direction.
2) Often when different users have suggestions about several related improvements - it means that we should consolidate them and rewrite subsystem to make it more flexible and configurable. So, bugs from users often just symptoms of the problem, not the problem itself - we shouldn't fix symptoms.

[andrew_bt2]

Dear Maxim,

Thank you for your reply. Nice to hear you may implement the field level security control in the future version. I am looking forward to see that one comes out.

I also thank you for your suggestion on how to deal with our problem with the current version of TrackStudio. However, I afaid we may not want to it this way because we would like to use TS to handle high volume of the daily bug reports and change requests for a large number of projects that involve multiple project managers and developers - It would be much easiler for them to deal with a single task from start to finish instead of moving back and forth with two tasks of the same bug/request. FYI, we have set the internal message types for developers and managers so that the internal exchanges and task assignments/reportings are invisible to the external users.

Just want to share our situation/requirement and perhap provide you an idea of future enhancement of the software.

Thanks!

Andrew

[admin]

Dear Maxim,

Thank you for your reply. Nice to hear you may implement the field level security control in the future version. I am looking forward to see that one comes out.

I also thank you for your suggestion on how to deal with our problem with the current version of TrackStudio. However, I afaid we may not want to it this way because we would like to use TS to handle high volume of the daily bug reports and change requests for a large number of projects that involve multiple project managers and developers - It would be much easiler for them to deal with a single task from start to finish instead of moving back and forth with two tasks of the same bug/request. FYI, we have set the internal message types for developers and managers so that the internal exchanges and task assignments/reportings are invisible to the external users.

Just want to share our situation/requirement and perhap provide you an idea of future enhancement of the software.

Thanks!

Andrew

OK, I understand. I think that more complex workflow with restricted handler list can solve your problem without move tasks.