Custom Objects is a concept to help customers configure IFS Applications. Custom Fields is a way to configure customer specific attributes to one specific installation of IFS Applications only by configuring IFS Applications. Custom Fields gives each customer the possibility to add fields they want to almost any Logical Unit. Custom Fields will have the same properties as any other attribute in the LU, this means that they are persistent, searchable and protected by IFS Applications security.
Please note that there is one big difference between a normal LU attribute and a Custom Field attribute and that is the fact that you can only have limited business logic connected to a Custom Field attribute without doing a customization.
The architecture of Custom Fields works as follows. A shadow LU is created for every LU that has a Custom Field. This shadow LU consists of one or more database objects, a table, a package, one or more views.
IFS Solution Manager is used to configure Custom Fields. This is where Custom Fields are configured and Custom Field code is generated and deployed. IFS Client frameworks uses meta data from Custom Fields to change how to handle Custom Fields when saving and retrieving data from a Custom Fields LU.
When deploying a Custom Field several new database objects might be created:
24DE63531ACB492685897482934EB7F2. The master table and the Custom
Fields table has a constraint that removes the Custom Fields record upon
delete of the master LU record.
Every IFS Applications Client that is supposed to handle Custom Fields must have the following functionality. It must be able to fetch Custom Fields Meta Data and act upon the meta data. When the client shall fetch data through a view it must check the meta data if there exists a Custom Fields view that should replace the ordinary view, then the client should query the Custom Fields view instead of the ordinary view. When saving any data the client must be aware of there are any Custom Fields that are changed. If there are changed Custom Fields attributes the client should call the Custom Fields package after saving the ordinary changes if there were any ordinary changes.
Custom Fields Meta data is fetched by calling Metadata procedures in Custom Fields system service (called Custom_Objects_SYS). Every Custom Fields LU has its own Meta Data. The Meta Data describes what the new Custom Fields database object is called and which attributes that has been added and also what properties this attribute should have in the client.
These are the different types of Custom Objects we have now:
Custom Fields can handle the following type of attributes:
Persistent fields are fields that can be used to store data. They can also be used find a specific entity in a query.
Read-only fields are fields that fetches its value from another field, the value can be fetched from some other LU or with some expression. These fields are read only, so you can not store any value in these fields. We have three types of Referenced Fields:
Local fields are fields that exists in the LU you are extending but for some reason not displayed in all views. You can then add a Local field and display it on the form where you want it to appear. Local fields can never be changed by an end-user.
Custom Fields is not supported in any business logic, meaning that you should not use Custom Fields in your business logic. IFS takes no responsibility for writing business logic against Custom Fields.
The only supported "business logic" that can be used against Custom Fields is Custom Defined Events and Custom Menus. In Custom Defined Events you can use Custom Fields as parameters in your Event Actions. In Custom Menus you can create Custom Menus with Custom Fields as parameters to a Quick Report.
Custom Fields can also be used in the following features/concepts:
The Administrator must make user that Custom Objects is visible in end-users Base profile or its Personal profile. If Custom Objects not are in any of an end-users profiles, then the Custom Objects will not be visible to the end-user. Read more About Profiles and Profile Repository.
Since Custom Fields is implemented as a "shadow" LU, with similar database objects as the master LU, the Custom Field LU can be administrated the same way as a normal LU. This means that security is applied in the same way on a Custom Fields LU as any normal LU, meaning that if you not are granted a view you can't use that view in a query from a client. In the same way any method in a Custom Fields package, if you not are granted a method you can't use it to save the data. In order to avoid such security runtime errors we check if the User is granted to any Custom Fields database objects before delivering the Meta data to the client.
Upon deployment of a Custom Field LU we creates a Presentation Object called cfX (where X is the LU name, for LU SalesPart we create a Custom Field PO called cfSalesPart). This presentation Object can be used to grant this functionality to the roles that should have this database objects grants.
The Custom Fields PO is always automatically granted to all roles that already is granted to the views you have added for this Custom Fields LU. When we deploy the Custom Field LU we also grants all necessary grants to the privileged users IFSSYS and IFSWEBCONFIG.
The Custom Fields concepts comes with an Exclude list. The Exclude list contains all LU's that can't be used together with Custom Fields.
Examples of reasons to put a LU on the Exclude list: