It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788

question asked: Nov 18 '14, 4:25 a.m.
question was seen: 2,316 times
last updated: Nov 20 '14, 6:28 a.m.

Related questions

FAQ - How this Forum works

RTC 3.0.1 Story WI Auto change state from close to new.

0
YOGESH LOKHANDE (104●4●19●27) | asked Nov 18 '14, 4:25 a.m.
 RTC 3.0.1 Story WI Auto change state from close to new.
it urgent if any one know why this happen please help me to fix this

Yogesh

Accepted answer

1
permanent link
Ralph Schoon (63.1k●3●36●46) | answered Nov 18 '14, 5:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A work item does not automatically change its state. If a state change is done, the history should indicate why. Please check the history.

One way to achieve this result is in changing the story to e.g. a task, save, change the type back to story, save.

Since the states are different in different workflow, this could result in what you describe.
YOGESH LOKHANDE selected this answer as the correct answer
Comments
YOGESH LOKHANDE commented Nov 19 '14, 1:37 a.m.

 I check same but that not afect the new Story WI

Can you please check below image 

and help me with resolve

YOGESH LOKHANDE commented Nov 20 '14, 6:27 a.m.

Thank you Ralph 

2 other answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Susan Hanson (1.6k●2●201●194) | answered Nov 18 '14, 6:39 a.m.
I agree with Ralph!

I've seen this in two cases:

1) you change the type of the work item and the state literal value for the Story "closed" state is not the same as the Task "closed" state (which is normal). 

2) If there are automated tools that use the APIs that tell RTC to do an Action against the story that either doesn't exist in that workflow or is not applicable for a Story in closed state.  For example, if an automated tool using the APIs tells RTC to do the action "Close" on a story that is already closed.  RTC seems to be "confused" and instead of giving an error, it "punts" back to basically the initial state, from what we've seen.

You should be able to see this in the history or at least, find out *who* was doing the saving when it changed.
Comments
Ralph Schoon commented Nov 18 '14, 7:03 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Susan, I assume this happens if you use the deprecated setState() method. I haven't seen this actually if I use the workflow and the action (which is the supported method, as the other one disrespects the workflow.

YOGESH LOKHANDE commented Nov 18 '14, 7:10 a.m.

Thank you Susan and Ralph,


It show that 
Intial history for this
Summary  Testing - FR Testing for location polling
Status  <none>
Type  Story
Project Area  Location_Products_CM


 and later it show this

Prajwal Gonnade  Nov 14, 2014 1:04 PM
Status  <none>  →  <none>


YOGESH LOKHANDE commented Nov 18 '14, 7:11 a.m.

 So I am get confuse ....


because all Story are set to New and in history it show same  for all

<none to <none>

<none> - to <New>

1
Susan Hanson commented Nov 18 '14, 7:15 a.m.

No, in fact it looks like we do workingCopy.setWorkflowAction(actionLiteral);

So if for example the story is already in Closed and we do a setWorkflowAction(closeActionLiteral) which would basically attempt to Close the work item.  Since there is no 'Close' action that you can do in the workflow when the state is already in Closed, RTC seems to be confused and actually dumps it back into (i'm guessing here) the Initialization state (which is Open in most cases).

We have a custom-bridge that we get into this case a couple of times since it makes some assumptions and sometimes the team on the other side of the bridge goes against these assumptions :-)

YOGESH LOKHANDE commented Nov 18 '14, 11:24 p.m.

But what we have to do with such issue ?


Please help on it 

1
sam detweiler commented Nov 18 '14, 11:46 p.m.

This doesn't answer the question,but Susan, you should use 

IWorkflowInfo.getActionResultState(Identifier<IWorkflowAction> actionId)

if the result is null, then you cannot execute that action
(I agree that it should throw an error if you try, and not cause a side effect)

YOGESH LOKHANDE commented Nov 19 '14, 12:11 a.m. | edited Nov 19 '14, 12:12 a.m.

Error  

My quest is related above image ...
how this happen ... and how I can resolve 

YOGESH LOKHANDE commented Nov 19 '14, 1:38 a.m.

Or how to restore the WI status back to  

Susan Hanson commented Nov 19 '14, 6:13 a.m.

Thanks Sam .. I'll add that into my bridge.

showing 5 of 9 show 4 more comments
0
permanent link
YOGESH LOKHANDE (104●4●19●27) | answered Nov 19 '14, 3:42 a.m.
edited Nov 19 '14, 10:35 p.m. 
	Root cause is at type and attribute workflow for story was selected as task workflow
	
	So we suggested to default that is user story workflow
 Story work items are show as uninitialized in eclipse client and in web it show in no like 1 to 3.
		 
	
	For this suggested
	
	Follow the steps
	
		 
	
		 
	
	Open work iteam
	
	Work item type -> story to task and save it
	
	And again task to story
	
		 
	
	you get the status
	
		 
	
	This is the only solution we have..
	
		 
	
	User is ok with it.
	
		 
	
	Yogesh
Comments
1
Susan Hanson commented Nov 19 '14, 6:15 a.m.

Right .... what is saved inside is the literal of the workflow and if you make changes to the workflow (like remove the Closed state and then even add one back in that has a display name of Closed), you'll see things like this because your new "Closed" state will have a different literal than your old "Closed" state.

Playing with workflows after you have any work items is, well, dangerous :-)

YOGESH LOKHANDE commented Nov 20 '14, 6:28 a.m.

Thank you Susan 

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.