Not all fields are visiblie in change History

I'm running into an issue where when I submit or transition an item, not all field changes show up in the change history. Currently, only 3 system fields show up, but other than that, any custom fields don't show up in change history. 

  • 0

    What version SBM?

    What change history are you looking at?  In the changed item or a custom report?

    Are the fields really being changed?

    How are the fields being changed?  I.e. by user on form, by AppScript or ModScript?

  • 0 in reply to 

    It is 11.4. (yes it is old)

    the 'Change History' tab on state form (in this case after submitting an item)

    The field data is being changed (I can confirm it by running a report. In this case, fields don't have data at the start and user adds data in submit transition).

    Fields are being changed by user. There are javascript and appscript component present too.

  • Suggested Answer

    0 in reply to 

    Maybe the user has limited the Change History in their settings???  My setting (below) is to show all changes.

  • Suggested Answer

    0   in reply to 

    I think you just said the key.. this is part of the submit. Submit is a special transition and is not the same as other transitions. It is normal for SBM to only record a few basic details about the act of submitting (state, owner, submit date, etc). It does not record the value of every field during a submit. In my head, I think of it like this: the item didn't exist "before" the submit, so it could not "change". If the field doesn't "change", it won't be recorded in the "change history".  All other transitions will record every change to every field.

  • 0 in reply to   

    This is the answer.  Great explanation of how "SUBMIT" is handled differently.

    For regular transitions, if there is a ModScript that is updating an item with "ExecuteSQL", then it is operating "outside the boundaries" of SBM.  I strongly suggest that if you are modifying an item in SBM (in a primary, aux or system table), use the appropriate ProjectBasedRecord, VarRecord, AppRecord and AppRecordList objects.  The methods associated with these objects will create the proper "change history" entries and will update other tables that are important.  Granted, there is a steep learning curve to understand all the functions and how and when to use them.

    Updating an SBM item using straight SQL requires the user to do a lot more work to keep all the tables aligned and keep SBM "happy".  

  • 0 in reply to 

    This does help with another issue. Thank you for sharing this.