I think I may have found a bug in the internal CRM JavaScript, and it is to do with retrieving the saveMode in form script.
As you may be aware, you can determine the save mode by executing executionObject.getEventArgs().getSaveMode() in form script. The return values that you can expect and their meaning can be found here: https://msdn.microsoft.com/en-us/library/gg509060.aspx.
This bug can be summarised as the saveMode being incorrectly reported if you save the record to correct a validation error while attempting to deactivate a record.
Sounds confusing? Follow these steps to reproduce this bug:
- Attach a script to the OnSave event for a form to report the saveMode
- Open an Active record
- Clear the value for a mandatory field on the form
- Deactivate the record. The form reports a validation error and the record is not deactivated.
- Enter some value for the mandatory field in step 3
- Click Save or Save & Close
- The saveMode is incorrectly reported as 5 (Deactivate). It should be 1 (if you clicked Save) or 2 (if you clicked Save & Close)
This bug can be problematic if you have scripts that checks for the saveMode and performs some logic on record deactivation. I haven’t found a workaround yet. This was tested on 2013 SP1 and 2013 SP1 UR1.
It seems like this has to do with a OOTB ribbon button sending or caching a deactivate SOAP request without validating form save compatibility. Depending on the circumstance, it might make sense to replace the Deactivate button with your own javascript button that enforces your form validation rules before sending the SOAP request to the CRM server to deactivate the record. Probably still qualifies as a bug though.