-
Notifications
You must be signed in to change notification settings - Fork 276
Description
The tables "Tenant Profile Page Metadata" and "User Page Metadata" contain blob fields ("Page Metadata" and "Page AL") that store the customization for pages. When we replace one field with another (e.g. when moving a field to another app or replacing its functionality), we write upgrade code to transfer the data from the old field to the new one. However, by doing so, the customization of the page will change since the old field references are no longer used. This leads to the problem that pages look different after each upgrade that involves such changes, as the new field won't be in the same place as the old one. Since this is only a technical change, customers expect everything to remain exactly as it was before the upgrade.
To meet these expectations, we added new functionality to our upgrade code, which opens the tables "Tenant Profile Page Metadata" and "User Page Metadata" as a RecordRef, reads the current customization from the blob fields, and replaces all references to the old field with the new field. In BC27.3.44504.0, this works fine, but with the upgrade to BC28.0.45058.0, it no longer does.
Please note that our product is a cloud solution, and there are no On-Prem installations. However, both tables have the scope set to OnPrem.
To emphasize the importance of this incident, we want to clarify that we performed over 800 upgrades last year and expect this number to further increase. If we have to invest 10 minutes to fix the profile customization for each upgrade, it would amount to 133 additional hours of work per year just to restore the state before the upgrade. Furthermore, every user will have to do the same to fix their own personalization, which will cause dissatisfaction among customers.
These tables must remain accessible or there has to be another solution that we can use to upgrade page customizations.
