| Parameter Name | Description |
|---|---|
| Custom Fields framework | Use this parameter to enable or disable custom fields functionality system wide. If this parameter is set to OFF no custom field will be available in any page. Also note, that related concepts that build upon custom fields, e.g., information cards, will also be disabled. |
| Info Cards framework | Use this parameter to enable or disable information cards system wide. |
| Conditional Fields framework | Use this parameter to enable or disable conditional fields system wide. |
| Custom Pages framework | Use this parameter to enable or disable custom pages system wide. |
| Tablespace for Custom tables | Tablespace where tables generated for Custom Objects should be created. |
| Tablespace for Custom indexes | Tablespace where indexes generated for Custom Objects should be created. |
| Tablespace for Custom LOB’s | Tablespace where Custom Objects, Large Objects should be stored. Default values for the Custom Objects tablespace parameters are the same as the application installation. The administrator should change these values if there is a need to separate custom and application storage. |
When publishing a Logical Unit, a presentation object is created for the new objects. This presentation object needs to be granted to the correct users / roles. For custom fields and information cards this is done automatically when publishing.
For more information about how to manage Presentation Objects see Manage Presentation Objects.
When a Logical Unit is unpublished, the Presentation Objects and the Custom Field views (CFVs) related to that Logical Unit are removed. The permission sets related to the Custom Field views are also affected, they are revoked. This goes for both Standard Logical Units and Custom Logical Units.
Example: There is a Logical Unit that contains a Custom Field attribute. If
the Logical Unit is unpublished, the Custom Field view is also removed. If the
removed Custom Field view was used by another Presentation Object (for instance
Quick Report) the view will no longer be available for that Quick Report after
unpublishing the Logical Unit. Since the view is no longer available, users that
previously could see the Quick Report cannot see it anymore after the Logical
Unit has been unpublished.
It is possible to see where a Database Object is used, in which components and
Presentation Objects:
When publishing a custom field configuration several new database objects are created, which shadow the original objects.
24DE63531ACB492685897482934EB7F2 that is unique. The master table and the
custom table has a constraint that removes the custom record if the master
record is deleted.
Custom objects architectural overview.
In runtime, the framework will automatically choose the database object to access depending on if a page has enabled custom fields or not. When fetching data either standard or the custom _CFV view will be used. When data is updated the framework will keep track of if a persistent custom field is updated. If needed the custom package methods are called after the standard methods are called.
The configurations are stored in the server. This meta data is used when administrating and creating database objects. The meta data is also fetched to the client in runtime where it is used by the framework to handle custom fields. The meta data fetched in runtime is cached in process memory. If the administrator is making changes to the configuration while users are working, the cache needs to be manually refreshed to get the new configuration.
Custom Objects works on a large majority of the pages in IFS Applications, but not everywhere. Custom objects require that the implementation of pages and their underlying storage conform to certain common patterns. Architectural decisions taken when implementing a page can make it impossible to associate a custom object with it.
For more information, see known Limitations.