Yes, I did. I spent more time fighting to try not to include them and generate a patch file which I could re-use. After an hour of that I just checked the files in so I can work in Rice without the overhead of reconfiguring every time.

As for the other branches - no I have not. I wasn't sure what the process was for that. Manual? Or merge of the 2.1 branch changes forward to the next one?

Manual merging is probably best.

Yea - it may take a little to merge it. I realized (after pushing it to 2.1) that I have no way to test it. There is nothing in the KEW integration tests or sample applications which would exercise this code. It's identical to what we have in production at UCD, but I'm not comfortable pushing a change to 4 versions of Rice without some assurance that there is not something stupid in there which might break workflow.

Now, this is not a blocker from a system operation standpoint. So, do you want me spending my time on that, or integrating into 2.5 only? I figure it will take a number of hours to figure out how to get the needed data and DD files set up within the integration test framework to test this properly.

Per discussion - will check in code to 2.1 branch and resolve this JIRA. A new JIRA will be opened to apply the changes to the other Rice versions after KFS has had a chance to test the results.

This change was rolled back. See KULRICE-14252 for instructions to reapply.