allowing a developer to add additional comments to a defect that is otherwise read-only
![](http://jazz.net/_images/myphoto/52a0fefcd5d6c2dd4a0dd373ec7b42da.jpg)
One answer
![](http://jazz.net/_images/myphoto/52a0fefcd5d6c2dd4a0dd373ec7b42da.jpg)
at first - I would say that there is a flaw in the workflow logic here - and this why you look stuck:
what you want is : ready to test --> read-only
but to me, if a discussion is necessary between tester and developer, possibly the status is not ready to test,
but rather "more information required" or "check with Dev"
But I don't have all the details.
In your context, I would try and use Read-Only Attributes For Condition,
and implement a scripted condition where I would test if the user performing the comment modification has the appropriate (Developer and/or Tester) role.
See https://jazz.net/library/article/1003/#conditions
That's the idea - though I did not test it.
Hope it helps.
Eric.
Comments
![](http://jazz.net/_images/myphoto/e5e63d5878217b64611c1df9401b7cd3.jpg)
To my knowledge it is unfortunately not possible to access the role of a contributor in JavaScript. See https://jazz.net/library/article/1093 Lab 5 for more information.
Another approach could be to create an Advisor. This is more complex, but allows to use a lot more API. Some hints on how to access the roles can be found here: http://rsjazz.wordpress.com/2012/10/01/adding-approvals-to-work-items-using-the-plain-java-client-libraries/ . The very similar client API might inspire iterating the team hierarchy: http://rsjazz.wordpress.com/2012/12/09/analyzing-a-aroject-areas-members-and-roles-using-the-plain-java-client-libraries/ .
An Advisor (others are participants) example: http://rsjazz.wordpress.com/2012/11/01/restrict-delivery-of-changesets-to-workitem-types-advisordelivery-of-changesets-associated-to-wrong-work-item-types-advisor/
Introduction into extending: https://jazz.net/library/article/1000
![](http://jazz.net/_images/myphoto/52a0fefcd5d6c2dd4a0dd373ec7b42da.jpg)
Just a comment on what the perceived workflow logic flaw is, mind you, this is not my call. I've been asked to implement this control on workflow, and I often find that, while I disagree with the workflow logic, usually it's a battle I lose, as some manager who says, tool X can do it, why can't RTC?
In this case though, I think I should have that capability. Often times once a ticket passes control from developer to tester, tester should have the capability to ask questions that a developer can reply to when a ticket is being verified. It may be because the instructions are vague, dealing with the 'works on my machine' questions, etc which may end up having the tester reject the ticket, but having a back/forth comment conversation being captured by RTC when a ticket is in the tester's realm I think is valuable, and also preventing a developer from changing ticket attribute values adhoc so only new changes are captured in the comments has some logic to me.
![](http://jazz.net/_images/myphoto/e5e63d5878217b64611c1df9401b7cd3.jpg)
Marc,
I know your situation. If you like to see such a capability don't hesitate to create an enhancement request for it. I have seen requests like that in the past and there might be requests for it already.
On the other hand, please keep in mind, RTC was initially designed to help agile, self organized teams to collaborate in an environment of trust, intending to make development more effective and successful that way.
So we are still a bit short of capabilities for environments that lack this quality and want or need to be more rigid and prevent users from doing things they think these should not be able to.
At this point, I can only tell you that I think it would be possible to write an Advisor that provides this capability.