How to manage multiple customizations for the same doctype

Frappe Framework Customization
1

Hi.

My teammates and I are working in different custom-apps, each of them has different doctypes, and of course, they customize some native doctypes from ERPNext, but we are facing some problems:

custom-app A add some fields to Item Doctype, and export customizations to A module, then custom-app B add other fields to the same doctype, and export them to B module.

When we install both custom-apps in the same site, changes seem to be overwritten, not all changes are reflected but only the last custom-app installed apply those changes

We have an idea that consists in unify those custom-apps, and instead working with different modules in the same custom-app, then exporting customizations to the same module and the problem would be solved. But then we face the following problem:

We work between different environments (testing and production) and we have, for instance, 2 modules, module A and B, we are developing module B but module A is ready to production, so we want to deploy it and doing it by ignoring module B, and of course, all its customizations (because module B customizations, can contain a link type field to a doctype created for the module B, and when doing a migration this will fail because that doctype does not exist at production environment)

I would be really thankful if someone can help us to manage this customizations that are needed from different modules.

1 Like
2

Hi @CaboGabo,
from my experience the only approach therefore is NOT to use “Export Customizations” but instead Fixtures.

We initially started also with “Export Customizations” but have seen the same challenge. Now we move all developments (at least, where we expect overlaps in different apps) to Fixtures. That seems a bit more effort as you have to add each individual customization within the hooks, but it is working in that scenario.

3

I’ve personally stopped using Customizations, and rarely touch hooks.py. I just make all my changes directly in the related App.

Why do I like working this way?

  • I no longer worry about reconciling Customizations that only exist in the SQL DB. There aren’t any.
  • I don’t have to worry about reconciling guerilla/monkey patches, versus the latest ERPNext code.
  • I can be confident that all custom changes are recorded on GitHub.
  • I can easily compare Official ERPNext vs. Client’s ERPNext. I run 'git difftool' using my favorite GUI, against the official upstream repo.
  • My clients can treat Customizations as “their space” to make small UI changes (field labels, descriptions, positions)

The disadvantage of working this way? When I upgrade ERPNext to a newer version, I have to spend a little time on Merging changes in git. I don’t upgrade often (couple of times a year). So far, this hasn’t been a big deal.

2 Likes