It's all about the answers!

Ask a question

allowing a developer to add additional comments to a defect that is otherwise read-only


Marc Towersap (481711) | asked Feb 13 '13, 12:43 p.m.
edited Feb 13 '13, 12:45 p.m.
 This is kinda an odd one.

I have developers who need to transition a defect into Ready-For-Test state.  At that point, the defect should be mostly read-only to the developer except for adding/responding to comments by a tester.  So I seem to be stuck.  I looked at prevent editing, which does most of what I want.  If I attach that Precondition to the developers on ready-for-retest, and enable 'Allow workflow actions', the developer can make changes to the defect then successfully switch it to ready-for-test.  However, should a tester (who now owns it) ask for clarification via a comment, the developer cannot respond back, because everything is read-only for the developer. 

Yet if I replace the 'Prevent Editing' with Read-only attribute for type and state, and enable the appropriate attributes to read-only (leaving out status and comment), then the developer can't make any changes to the defect other than adding comments when changing the state to ready-for-test, which is also not what I want. There can be many other reasons (like if the developer forgets to change ownership to a tester), change the due date, severity, etc. Opening up holes to make these additional attributes writeable means they're writeable from then on for that state.

What I want is for the developer to have full permissions to change whatever they want and be able to successfully transition to ready-for-test, but once it's in ready-for-test, it should be read-only for everything but comments.  Neither option seems to work for me.

It would be nice if 'prevent editing' could also pick/choose which attributes are exempt from the 'prevent editing' rule.

One answer



permanent link
Eric Jodet (6.3k5111120) | answered Feb 14 '13, 3:23 a.m.
JAZZ DEVELOPER
Hello Marc,
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
Ralph Schoon commented Feb 14 '13, 3:39 a.m. | edited Feb 14 '13, 3:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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


Marc Towersap commented Feb 14 '13, 10:50 a.m.

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.


Ralph Schoon commented Feb 14 '13, 11:39 a.m. | edited Feb 14 '13, 11:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.