Including changes to built-in Object in a Custom Module

Suneel Jhangiani asked on December 12, 2016 20:22

I'd like to know what is the recommended way to include a change to a built-in modules class within a newly created custom module.

As an example, in a custom module we have code that requires a 'CustomerType' field in the Customer class within the Ecommerce module. How could I include the addition of this field in my Custom Module and what about removing this field on uninstallation?

In adition, using the same example, we set the field to be hidden by default and then enable it on a couple of the Alternative Forms (ie. General properties & New Customer), so that only users who can view the admin interface will be able to see the field. Hence, we also need a way to re-define the alternative forms.

For our own usage its not much of a problem as we can Import a previously Exported customer object, prior to installing the module. However, this would cause issues if another module also customizes the same object.

custom module class

Recent Answers

Roman Hutnyk answered on December 13, 2016 11:11

Check the documentation on how to customize system objects.

I'd recommend to reference Customer in your custom class - add CustomerID field where you'd store a reference to a customer record. Having customer id you can use Kentico API to fetch that record and access any field you need.

0 votesVote for this answer Mark as a Correct answer

Suneel Jhangiani answered on December 13, 2016 14:02 (last edited on December 13, 2016 14:04)

Thanks for the response Roman, however, I am not sure you understood the question properly as it isn't about our own Custom Classes and code as such.

Let me try another way of explaining it:

Our custom module is created as an installable NuGet package. The issue we are facing is that when installing the module on a clean / new instance of Kentico the CustomerType field we added to the Customers table is not created.

As a fix we need to import a modified version of the Customers object as a seperate manual step in the installation.

This is fine for now, but what happens if another Modules installation also requires a new version of the Customer object (especially if developed by another company)?

I did read the documentation you linked to, but I don't see how that is applicable in this scenario. Unless you are suggesting we create a totally new Class to hold the CustomerType and have that as a 1 to 1 relationship with the Customer class.

The latest documentation (in particular https://docs.kentico.com/k10/custom-development/editing-system-tables ), does seem to imply that we should be customizing the Customer class in the way we have.

0 votesVote for this answer Mark as a Correct answer

Roman Hutnyk answered on December 13, 2016 14:13

I think creating of 1 to 1 relation is what they suggest in fact and I think it is a good approach in you scenario with custom module as nuget packega as it allows multiple extensions of the system classes (especially if another Modules installation also requires a new version of the Customer object).

https://docs.kentico.com/k10/custom-development/editing-system-tables works well in case you want to extend some class for your installation, but does not work for distibuted module.

0 votesVote for this answer Mark as a Correct answer

Suneel Jhangiani answered on December 14, 2016 15:15

It does make things more complicated for integrating with the Kentico Admin UI and I'd like to know what your recommendation would be, as it is no longer a simple case of modifying the Alternative Form in the customers class.

0 votesVote for this answer Mark as a Correct answer