Script behavior change with updates - scripts broken

[ForrestJudd]

Something appears to have changed in the November update that has broken some of our functionality.  It has also altered some of the default tenant functionality.  The underlying change appears to be related to when item detail fields are populated during item creation.

The clearest example of this behavior change is with the default tenant's RFQ workspace.  Prior to the November update, when you cloned an RFQ, the new RFQ retained the old RFQ number.  Ideally this is to tag multiple RFQs for the same request to different vendors with the same name.  I always thought this was desired behavior, as evidenced by the On Creation script in the default tenant for the RFQ workspace:

/*
Setup:      Needs RFQ_NUMBER field to write to
Purpose:    creates a new RFQ number, only for new, not cloned
Method:     If existing field is null, generate new number
Result:
*/
var RFQSeqID = '332';
var seqGenator = loadItem(RFQSeqID);

if(item.RFQ_NUMBER === null)
{
    //set the new number
    var newRFQNumber = nextSeqNumber(RFQSeqID);
    if(newRFQNumber !== null){
        item.RFQ_NUMBER = newRFQNumber;
    }
}//end if

 This script no longer works.  Here's what happens now.  I start with a newly created RFQ:

Notice the script runs during creation and assigned a new RFQ number - RFQ-100003.  I then clone the RFQ.  Prior to this weekend, it would have the same RFQ number.  Here's what I get now:

I modified the comments during the creation of the clone.  Notice that it was given a new RFQ number.  Look at its change log:

It's showing the RFQ Number field as having no value, but that's definitely not the case.

This has currently broken one of my important scripts.  I have scripting that takes grid information from cloned RFQs and upon RFQ approval updates the original master RFQ with vendor-supplied information.  To accomplish this I have a picklist on the RFQ item details that links back to itself only if the RFQ is not a clone.  This way each cloned RFQ has a link back to the RFQ that spawned it.  

I'm really not sure what's going on here.  I have other scripts that are acting on new item creation where some item fields ARE populated to start with.  Take this example:

Notice the GRIDFIELD item detail field started with a value.  The above record was created via script that invokes the createNewItem library function.  That funtion takes in an array of item detail fields and values, and the GRIDFIELD item detail field was included in that array with the call to createNewItem.  RFQ Number and Master RFQ was not, however, and (as expected in this case) they were assigned a value.  Now when I clone the above RFQ I get this:

The change log at least reports that those item detail fields suddenly had no value again.  Was this an intended change?  If so, what is now the recommended way to get back to the default functionality for RFQs where cloned RFQ records share the same RFQ number as the original record?

[michelle.stone]

Forrest - I'll create a case and start investigating this for you.  I'll circle back with the communtity once we know more.  Thanks for reporting.

Michelle

[jared.sund]

Forrest,

From my quick testing, this issue appear to only apply to field with editability set to false.  I'll address this with development first thing, and get this resovled quickly.

-Jared