Error dialog box on submit of Change Request

[rhermann]

I need to have an error message popup if a user selects “Not Applicable” for BOTH of the attributes pictured below (attached).  This error message would trigger on submit or when the user clicks on next. Anyone know the code to do this?

[BineshKumar1]

One option is to write a auser-defined javascript function, which will be called when a wizard step is completed but before next step is loaded.

<script type="text/javascript">        
function validateStep() {
                 ...    
return true;} 
</script

You can read more details about it in http://support.ptc.com/WCMS/files/165581/en/10_2_M030_WindchillCustomizationGuide.pdf Pg#831.

You also have an option to write a data utility and do this validation from the server side, more details on Re: GUI validation on an IBA attribute value.

Thank you

Binesh Kumar

Barry Wehmiller

[rhermann]

Binesh,

Thanks for the suggestions and documentation.  I like the idea of the user defined javascript function.  I was hoping I would be able to just drop some java code into the transition of a workflow task to validate when the users hits submit or next on the wizard but i do not see a spot in the workflow template administration to add this in....

Where exactly or which file would I be editing/adding this new javascript to so I get the desired functionality on the Wizard side?

-Ryan

[emartínez]

I would go for the option to extend the ootb form processor and throw an exception if this values are selected better than writing this in javascript

[rhermann]

Edmond,

If you could provide a little more detail it would be very helpful.  Code would be great however just a bullet list of the things I would need to edit and where I would need to drop code would also be helpful.  I can figure out the syntax if I need to but I want to make sure I put everything in the right place.

Regards,

Ryan

[emartínez]

You can modify the Change Request form processor modifying "create" entry of the following file:

<windchill>/codebase/config/actions/ChangeManagement-actions.xml

Specifically:

<action name="create" uicomponent="CREATE_CHANGEREQUEST" ajax="component">

         <description>Create a change request</description>

         <command class="com.ptc.windchill.enterprise.change2.forms.processors.CreateChangeRequestFormProcessor" method="execute" windowType="popup"/>

         <includeFilter name="OptionSetLocalRuleContextFilter"/>

         <includeFilter name="sandboxSharingValidationSimple"/>

         <includeFilter name="restrictGuestMembers"/>

         <includeFilter name="manAuthorized"/>

         <includeFilter name="adminLockModifyChangeObjectsFilter"/>

</action>

By changing the "class" attribute. You can extend the OOTB form processor and do your extra checks and throw an error if necessary, everything should be inside the CommandBean object.

I think the supported way to do this is adding this entry with the modifications inside the "custom-actions.xml" file, so it will not be modified on an upgrade or patch install

Regards,

Edmond

[LoriSood]

Ryan, were you able to get what you needed using either Edmond's or Binesh's suggestions? If so, could you mark the thread as answered for the benefit of the community?

[rhermann · Accepted solution]

Lori,

Although Binesh's and Edmond's suggestions were both technically possible the customer is strongly against any customization to the windchill environment that may not be fully upgrade-able in the future.

Instead of making a customization to the new change creation wizard itself, I added an "Error handling" workflow task which would get sent to an administrator, advising them that both attributes were set to "Not Applicable" and that they need to go in and edit the Change in order to make a valid selection because current combination was invalid.  I used a conditional with some code in it to analyze these attributes and only send it down the error handling path if BOTH of the attributes were set to "Not Applicable".  After the administrator went in and edited it and completed their task the workflow would then "loop" back to the conditional to once again evaluate the attributes.  This met our needs and avoided the full-on customization.

Regards,

Ryan Hermann