This change as it is would break references. The UI needs to generate a unique identifier for each referenceable item - such as Entity of Interest - so that it can be cleanly referenced elsewhere, i. e. in Derived Parameters. Current schemas appear to have the id field that can be used for such purpose.
The comment in the script is, perhaps, not very clear. Fields that are marked as autogenerated still have values generated by the UI, it is just that the UI makes them automatically and does not allow users to change them. For fields that are really supposed to be generated by the backend only when the record gets deposited it would be more appropriate to have a special category and not include such items in the UI at all. Does that make sense...?
This change as it is would break references. The UI needs to generate a unique identifier for each referenceable item - such as Entity of Interest - so that it can be cleanly referenced elsewhere, i. e. in Derived Parameters. Current schemas appear to have the
idfield that can be used for such purpose.The comment in the script is, perhaps, not very clear. Fields that are marked as
autogeneratedstill have values generated by the UI, it is just that the UI makes them automatically and does not allow users to change them. For fields that are really supposed to be generated by the backend only when the record gets deposited it would be more appropriate to have a special category and not include such items in the UI at all. Does that make sense...?