Importing a scoped app deletes/changes a task table field


If an update set is committed with a DELETE update for a field on the child table and the field on the target instance is defined on the parent table, it is dropped it from the parent table.

Steps to Reproduce

  1. Create a scoped application

  2. Create a standalone scoped table with a column named "number"
    Note that scoped fields do not get a 'u_' prefix, so on the database/dictionary/storage alias level, the field name can match an OOB field name

  3. Delete the standalone scoped table

  4. Create the same table again, this time extending Task

  5. Open the application record and publish it to an update set
    Note that the update set contains delete updates for the table and the number field

  6. Import the update set on the target instance and preview it
    Note that the update set now contains an insert and delete updates for the same table (which will be created in task hierarchy) and a delete update for number field

  7. Commit the update set

  8. Open the task.number dictionary record
    Note that the record is broken and no label is shown
    Confirm there is no task.number field on lists and forms of task tables



Avoid use of out of box (OOB) field names in scoped applications.

Always check the update set, especially the sys_db_object and sys_dictionary updates as these may trigger schema changes. Special attention should be give to updates with DELETE action.

Related Problem: PRB1253960