ERPNext Conference 2019* Blog

Refactoring of contact in V12


Dear colleagues,

noted that in v12.1.1, contact has been refactored in a way to support multiple email addresses and phone numbers through a child table. I do understand that in some cases this was requested - while for the majority of use cases it is actually more cumbersome (phone - add line - fill data vs. enter data).

To note here: the mobile_no field has been dropped, consider this for compatibility. Also, old values in email_id and phone are maintained in a read-only field. I propose a script that will fill these values when saving from the child tables, as this is easier to work with in reporting.

The following custom script will insert blank lines for both child tables:

frappe.ui.form.on("Contact", {
    refresh: function(frm) {
        if (frm.doc.__islocal) {
           // not yet saved
           if (frm.doc.links) {
           // add blank lines for child tables
           var email = cur_frm.add_child('email_ids');
           var phone = cur_frm.add_child('phone_nos');


And this will restore the values to the old fields:

before_save: function(frm) {
  try {
    cur_frm.set_value("email_id", frm.doc.email_ids[0].email_id);
  } catch { /* do nothing */ }
  try {
    cur_frm.set_value("phone", frm.doc.phone_nos[0].phone);
  } catch { /* do nothing */ }
  try {
    cur_frm.set_value("mobile_no", frm.doc.phone_nos[1].phone);
  } catch { /* do nothing */ }

SMS Alert: Doing it by Js and python

Hey @lasalesi ,

  • The patch for contact moves the existing email_id, phone and mobile_no to the respective child tables and it sets the existing email_id as primary and the same for phone and mobile_no fields.
  • So you do not need to do custom scripting to add the values to the child tables.



Hello - thanks for the update. If mobile_no field is dropped - then send SMS will go to the primary number for contact?


Hi @hrwx,

actually, the script does exactly the opposite, they copy the table content back to the “old” field, because the evaluation of data from these is much simpler and we have many reports based on these fields.


Hi @zerodiscount,

good point, but I have not tested that. Maybe someone from the core team can comment on this.


And here a side note: trying to revert this, because in many cases the old way was much easier and more user friendly, I came across this - sorry - annoying message:


Why to block this? Please, at least let the people revert back if they want to…


I tried to change mobile_no from Read Only to Data - and it gave same error. I have a suggestion for the team:

In case of phone numbers - the check mark should be changed from Is_primary to Is_mobile. The first row of child table becomes the primary number - as you can move rows up or down. And default mobile_no is the first mobile number in child table… This way new and old way are enabled - I think.


Found the way to workaround the “You cannot unset …”:

  • open “tabDocField”, navigate to parent = “Contact” and fieldname in (“email_id”, “phone”) and set read only = 0
  • go to Contact > Customise and make sure it is not set, hide child tables if they are not used
  • clear the content of tabContact Email and tabContact Phone (otherwise it will override edits)


Hi @zerodiscount ,

yes the SMS will go to the default number now.



Hi @lasalesi,

The whole point of refactoring Contacts was to list all the available phone number in one Contact itself and not create multiple contacts to store multiple phones.



Hi @hrwx,

understood, but this solution with the child tables is for many customers a pain to work with, therefore, we need a way to go back/reconfigure (which I have now posted above).

Again, I do understand that in some cases, multiple phone numbers/emails are requested; this could easily be added/customised where requested. But dropping the well-established system and even making a fall-back rather hard raises questions about the review process for new changes. Usability should always be considered, if you have to use child tables to add a single number, it requires unnecessary extra clicks (also when editing).

If you have a child table for the phone numbers, consider adding a classification/type column (“business”, “mobile”, “private”), the primary might not be the mobile…


@hrwx I would recommend bringing mobile_no back since its a breaking change. Those who do not want to use it can hide it.


Hey @lasalesi @rmehta,

  • Will restore the mobile_no field in the form again.
  • Mobile and Phone can be set from the child table.



Hey @lasalesi @rmehta

  • Reintroduced the mobile field again.
  • #8404