starred/SuiteCRM-SuiteCRM

Fork 0

mirror of https://github.com/SuiteCRM/SuiteCRM.git synced 2026-03-02 19:16:58 -05:00

Email address InlineEdit not working (Contact, Account, ...) in SuiteCRM 7.x #4857

New issue

Open

opened 2026-02-20 16:25:04 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-20 16:25:04 -05:00

Owner

Originally created by @gody01 on GitHub (Sep 12, 2022).

Issue

Inline Edit of Email adress in Contact, Account doesn't save new Email.
It works in Version 7.11.18

On Contact or Account detail view, when You try to change Email address with inline edit, after confirming change, Email changes back to original and change is not saved.

Expected Behavior

Changed Email should be saved and displayed.

Actual Behavior

Changes are not saved, and old Email address is displayed in UI also.

Possible Fix

Steps to Reproduce

Open Detail View of Contact ot Account with defined Email address
Click on Edit icon on Email field
Make change to Email Address
Click on save icon or press enter
Changed Email revert to old Email. On page refresh, there is still old Email too (change not not saved to DB).

Same steps in 7.11.18 normaly changed and saves new Email adress

Context

Trying to correct Email address with inline editing.
Has to Edit complete record, to make change to Email adress.

Your Environment

SuiteCRM Version used: 7.12.5 & 7.12.7
Browser name and version Chrome, Firefox / linux, windows
Environment name and version Mysql: mariadb-server-10.3.32, php-7.3.33 (SuiteCRM 7.12.7)
Environment name and version Mysql: mariadb-server-10.3.28, php-7.3.33 (SuiteCRM 7.12.5)
Operating System and version Linux RHEL 8, CentOS 8, RockyLinux 8

Originally created by @gody01 on GitHub (Sep 12, 2022).     #### Issue Inline Edit of Email adress in Contact, Account doesn't save new Email. It works in Version 7.11.18   On Contact or Account detail view, when You try to change Email address with inline edit, after confirming change, Email changes back to original and change is not saved. #### Expected Behavior  Changed Email should be saved and displayed. #### Actual Behavior   Changes are not saved, and old Email address is displayed in UI also. #### Possible Fix  #### Steps to Reproduce   1. Open Detail View of Contact ot Account with defined Email address 2. Click on Edit icon on Email field 3. Make change to Email Address 4. Click on save icon or press enter 5. Changed Email revert to old Email. On page refresh, there is still old Email too (change not not saved to DB). Same steps in 7.11.18 normaly changed and saves new Email adress #### Context   Trying to correct Email address with inline editing. Has to Edit complete record, to make change to Email adress. #### Your Environment  * SuiteCRM Version used: 7.12.5 & 7.12.7 * Browser name and version Chrome, Firefox / linux, windows * Environment name and version Mysql: mariadb-server-10.3.32, php-7.3.33 (SuiteCRM 7.12.7) * Environment name and version Mysql: mariadb-server-10.3.28, php-7.3.33 (SuiteCRM 7.12.5) * Operating System and version Linux RHEL 8, CentOS 8, RockyLinux 8

deekerman added the

labels

2026-02-20 16:25:04 -05:00

deekerman commented

2026-02-20 16:25:06 -05:00

Author

Owner

@pgorod commented on GitHub (Sep 13, 2022):

Perhaps related to this change?

#9409

Can you please try undoing that change and see if it fixes your bug?

@pgorod commented on GitHub (Sep 13, 2022): Perhaps related to this change? #9409 Can you please try undoing that change and see if it fixes your bug?

deekerman commented

2026-02-20 16:25:06 -05:00

Author

Owner

@gody01 commented on GitHub (Sep 13, 2022):

Unfortunately not.

Request, which returns old Email is:

"GET /index.php?module=Home&action=saveHTMLField&field=email1&current_module=Contacts&id=7f117037-082a-fad4-66a5-62e8e66af2a2&value=mail.address%40domain.si&view=DetailView&parent_type=&to_pdf=true HTTP/1.0" 200 369 "https://crm.gody.si/index.php?action=ajaxui"

@gody01 commented on GitHub (Sep 13, 2022): Unfortunately not. Request, which returns old Email is: "GET /index.php?module=Home&action=saveHTMLField&field=email1&current_module=Contacts&id=7f117037-082a-fad4-66a5-62e8e66af2a2&value=mail.address%40domain.si&view=DetailView&parent_type=&to_pdf=true HTTP/1.0" 200 369 "https://crm.gody.si/index.php?action=ajaxui"

deekerman commented

2026-02-20 16:25:06 -05:00

Author

Owner

@gody01 commented on GitHub (Sep 13, 2022):

       if (($bean->ACLAccess("edit") || is_admin($current_user)) && $enabled) {
            $bean->in_workflow=true;
            if ($field == 'email1') {
                $bean->email1_set_in_workflow=true;
            }
            if (!$bean->save($check_notify)) {
                $GLOBALS['log']->fatal("Saving probably failed or bean->save() method did not return with a positive result.");
            }
        } else {
            $GLOBALS['log']->fatal("ACLAccess denied to save this field.");
        }
---> up to here $bean->field is still correct (new)

        $bean->retrieve();

---> here old email is retrieved

It looksl. like function $bean->save wouldn't save email1. But it doesn't return false ...

@gody01 commented on GitHub (Sep 13, 2022): ``` if (($bean->ACLAccess("edit") || is_admin($current_user)) && $enabled) { $bean->in_workflow=true; if ($field == 'email1') { $bean->email1_set_in_workflow=true; } if (!$bean->save($check_notify)) { $GLOBALS['log']->fatal("Saving probably failed or bean->save() method did not return with a positive result."); } } else { $GLOBALS['log']->fatal("ACLAccess denied to save this field."); } ---> up to here $bean->field is still correct (new) $bean->retrieve(); ---> here old email is retrieved ``` It looksl. like function $bean->save wouldn't save email1. But it doesn't return false ...

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@pgorod commented on GitHub (Sep 13, 2022):

There seems to be some additional logic for this in include/SugarObjects/templates/company/Company.php and include/SugarObjects/templates/person/Person.php

I wonder if it makes a difference if you're changing to an email that already exists in EmailAddresses table; or to one that doesn't exist there yet. I know that the email1 field is just short-hand for "the first related email in EmailAddresses table", but keeping those two bits of data in sync sometimes gets complicated...

@pgorod commented on GitHub (Sep 13, 2022): There seems to be some additional logic for this in `include/SugarObjects/templates/company/Company.php` and `include/SugarObjects/templates/person/Person.php` I wonder if it makes a difference if you're changing to an email that already exists in EmailAddresses table; or to one that doesn't exist there yet. I know that the **`email1`** field is just short-hand for "the first related email in EmailAddresses table", but keeping those two bits of data in sync sometimes gets complicated...

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@gody01 commented on GitHub (Sep 13, 2022):

Yes, I compared debug logs from 7.11.18 and 7.12.7 and in 7.11.18 there are queries to:
email_addr_bean_rel
table, while in 7.12.7 there is none.

@gody01 commented on GitHub (Sep 13, 2022): Yes, I compared debug logs from 7.11.18 and 7.12.7 and in 7.11.18 there are queries to: email_addr_bean_rel table, while in 7.12.7 there is none.

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@gody01 commented on GitHub (Sep 13, 2022):

Just tested.
Changing to existing email address also doesn't work.

@gody01 commented on GitHub (Sep 13, 2022): Just tested. Changing to existing email address also doesn't work.

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@timo-ecm2 commented on GitHub (Oct 10, 2023):

I have tested this one in the current version 7.12.13, and as expected, it is still present.

@timo-ecm2 commented on GitHub (Oct 10, 2023): I have tested this one in the current version 7.12.13, and as expected, it is still present.

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@phil8900 commented on GitHub (Oct 6, 2025):

The issue still exists in Version 7.14.7.

@phil8900 commented on GitHub (Oct 6, 2025): The issue still exists in Version 7.14.7.

deekerman commented

2026-02-20 16:25:07 -05:00

Author

Owner

@phil8900 commented on GitHub (Oct 6, 2025):

Could someone take a look at the fix proposed here?

It seems to work.

@phil8900 commented on GitHub (Oct 6, 2025): Could someone take a look at the fix proposed [here](https://community.suitecrm.com/t/suitecrm-7-13-inline-edit-not-working-for-email-in-leads-module/97923)? It seems to work.