States on Custom Tables (this is embarrassing)

[Uncle Rob]

So I have a custom task type with several states, 3 of which are considered "Closed".

Since all my workers and customers work off of Task lists, I opted to modify choices for Task.State rather than make a custom table based state.

Ok, so I created all my state choices and the three "Closed" ones have values of 50,60,70 respectively.   I did a dictionary override for my custom table and listed them in the close_states attributes (per this wiki page)

My problem is no matter which of the ending states I pick, the system interrupts and sets the State value to 3.  
Suspecting the "Task Active State Management" business rule was to blame, I deactivated it, and sure enough, I could pick whatever closure state I wanted unmolested.

My problem is, I can't figure out how or why Task Active State Management is determining that I want a default State of 3 on inactivation.

Anyone run into this kind of thing before?

[Brad Tilton]

So is an blog older post, but worth trying. Take a look at the second to last paragraph.

[Uncle Rob]

Well, punch me straight in my eye.   That'll learn me for searching for "script contains state".   Task Closer just sets the field values directly, so it was flying under my radar.   But that little bastar-   Wait... if I deactivate TaskActiveStateManagement the strange behavior stops.   How could that be?

[Uncle Rob]

DURRRR!!!     Because Task Closer looks for a change in Active, and if you inactivate "Task Active State Management" then it won't cause the Active flag to change.  

Come on Robert Fedoruk - Wake up dude!

[Uncle Rob]

I wonder if something was re-broken in Fuji, since Valor Poland seems to indicate in his blog post that PRB572779 would resolve the issue.   Or maybe a fix never made it to release?