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) {
//find_default_coordinates(frm.doc.links[0].link_name);
}
// add blank lines for child tables
var email = cur_frm.add_child('email_ids');
cur_frm.refresh_field('email_ids');
var phone = cur_frm.add_child('phone_nos');
cur_frm.refresh_field('phone_nos');
}
}
});
And this will restore the values to the old fields:
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.
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.
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.
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.
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…
Hi @hrwx - thanks for your effort - noticed the mobile_no is restored with latest release.
Now that email_id is also in a child table - what is the field name for primary email_id ? I am trying to link / pull the default transporter (supplier) email_id for delivery note. How to fetch the primary / default email_id from new child table?
Thanks again for your efforts in restoring mobile_no.
@hrwx - thanks. I guess my query also relates to how to pull the contacts for transporter that is selected from a list of suppliers in the delivery note. I am creating a Read Only custom field called transporter_email of type Data, Option Email and attempting to fetch the email id of the transporter.
when I try to fetch transporter.email_id - it gives me an error (invalid fieldname). should be transporter.contacts.email_id? or the option should be contacts and fetch should be email_id? in which case how would it link to transporter? Sorry to bother you with specifics - but I have been stuck on pulling the default email id associated with the transporter.
I’ve got the same issue of fetching the email automatically now that it is in a table.
I tried using email_id with the same syntax as what was previously used (in customize form, not in a custom script), but this does not work. Any ideas on what I am doing wrong?
in your case, it should work with contact_person.email_id because on save the child table primary value will be stored in the “email_id” field (retrofit). There were a few hickups in the releases on version-12, make sure you are on 12.1.6 (or later)…