Introduction
From Oracle E-Business Suite Mobile Foundation Release 6.0 onward, administrators can customize seeded approvals metadata defined while configuring messages from Approvals Data Services Manager. Customization allows administrators to change the way the configured data displays on the Approvals app. Customization support helps in :
- Protecting Oracle Development seeded meta-data from being inappropriately updated by customers.
- Protecting custom configuration changes done by customers from being overwritten by standard updates provided by Oracle Development.
The protection offered by customization depends on the customization level (Core, Limit or User) at which a particular component is set. Approvals metadata has various components which can be customized like Message/Header attributes, Regions, Views and View attributes.
Understanding customization levels
Core : No changes can be made to components set at this level. Component’s properties can be viewed but update is not allowed.
Limit : Component at this level can be enabled/disabled for display in the approvals app, but no other changes can be made to the component.
User : Component set at this level are allowed to be modified fully. Most of its properties can be customized. This customization level is automatically set while defining custom configurations.
Approvals component hierarchy effect on customization levels
In Approvals metadata, there is a parent child relationship maintained between Regions to Views and Views to View attributes. Customization levels also honor this hierarchy such that a child definition is at least as restricted as parents’. Table(a) describes possible value of customization levels:
| Parent level | Possible child level |
| Core | Core |
| Limit | Core, Limit |
| User | Core, Limit, User |
(a)
Applying customized configuration
There are two cases which occur when uploading approvals metadata into target instance :
- Customization levels are changed : When Oracle Development updates seeded approvals metadata, then components in that metadata can have changed customization levels. In this case, modification of customization level only from strict to less strict level is allowed, but not the other way because configuration can become less customizable than at existing less strict level. Table(b) describes customization level changes allowed.
- Data is changed : Data is uploaded into target instance considering existing customization levels and is uploaded such that configuration doesn’t loose any existing customized data based on table(b).
| Existing value | Possible new value | Data upload rule |
| Core | Limit, User | Whole new data is uploaded for the components with this customization level, as no customization was allowed. |
| Limit | User | Except the Render and Status properties (if present) for the component with this customization level, data is uploaded as these properties were customizable and could have changed. |
| User | No Value | No new data is uploaded for components with this customization level. |
(b)