Changes to "Create custom field" modal
- To improve parity with our API, we have added a new field type of "Integer", that allows you to define fields that store whole numbers only (no decimal places).
- The "Number" field type has been changed to "Decimal" to better align with the new "Integer" field type.
- "Reference" field type has changed to "Lookup", see below.
- Added a new "Has many" field type, see below.
Changes to the "Reference" field type:
- Prior to this change, the platform would create two fields when you created a field of type "Reference". A "Lookup" field on the Object where you created a reference, and a "HasMany" field on the object that was being referenced. You also had no control over what name and label was assigned to the HasMany field, and the default was not accurate, which could result in a naming conflict that could break GraphQL for the tenant (known bugs, ENG-39957, ENG-31484).
- We have replaced Reference with these two underlying field types, "Lookup", and "HasMany".
- If you create a Lookup, you can optionally create a HasMany, and you can supply your own name and label. We will block any names that cause conflicts in GraphQL, fixing the previously mentioned bug.
- If you choose to not create the HasMany as part of the creation of the Lookup, you can do so later by using the new "HasMany" field type in the Create.
- We've created new documentation to help people understand Lookups and HasManys.
Changes to the Custom Fields list when looking at an Object:
- The field type displayed in the list of fields is now consistent with the field types you can choose from in the "Create custom field" modal.
- For field types of "Lookup" or "Has many" the name of the object being referenced is displayed in brackets and is a hyperlink to that object.