starred/SuiteCRM-SuiteCRM

Fork 0

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

Users cannot be edited + Inbound email settings cannot be opened #5323

New issue

Open

opened 2026-02-20 16:59:38 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 16:59:38 -05:00

Owner

Originally created by @brunt82 on GitHub (May 26, 2025).

Issue

We recently updated our SuiteCRM instance from 7.14.6 to 8.8.0. We're now experiencing the following error (although it may have already existed in 7.14):

When we try to edit a user or open the email inbound settings, a blank page appears, and the browser logs an HTTP-500 error.

The following stack trace appears in the Apache log:

[Mon May 26 11:08:58.338957 2025] [php:error] [pid 117641:tid 117641] [client 10.161.0.4:55641] PHP Fatal error: Uncaught Error: Call to a member function getPreference() on bool in /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php:6953\nStack trace:\n#0 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(6887): InboundEmail->calculateSignature()\n#1 /opt/SuiteCRM-8.8.0/public/legacy/data/SugarBean.php(4752): InboundEmail->fill_in_additional_detail_fields()\n#2 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(381): SugarBean->retrieve()\n#3 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(6704): InboundEmail->retrieve()\n#4 /opt/SuiteCRM-8.8.0/public/legacy/modules/Emails/EmailUI.php(1371): InboundEmail->retrieveAllByGroupId()\n#5 /opt/SuiteCRM-8.8.0/public/legacy/modules/Emails/EmailUI.php(298): EmailUI->getMailboxNodes()\n#6 /opt/SuiteCRM-8.8.0/public/legacy/modules/Users/views/view.edit.php(296): EmailUI->displayEmailFrame()\n#7 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/View/SugarView.php(210): UsersViewEdit->display()\n#8 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/Controller/SugarController.php(434): SugarView->process()\n#9 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/Controller/SugarController.php(365): SugarController->processView()\n#10 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/SugarApplication.php(101): SugarController->execute()\n#11 /opt/SuiteCRM-8.8.0/public/legacy/index.php(52): SugarApplication->execute()\n#12 {main}\n thrown in /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php on line 6953, referer: https://suitecrm-test-ng.domain.de/

By adding the following lines of code in public function calculateSignature() we work around the problem:

if (!$owner || !($owner instanceof User)) {
        if (isset($GLOBALS['log'])) {
            $GLOBALS['log']->fatal("calculateSignature: Benutzer mit ID '$createdBy' konnte nicht geladen werden.");
        }
        return;
    }

Thanks to the additional log line, we were able to determine that the retrieved user IDs actually no longer exist in the database. The user IDs can be found in the "created by" column of the "inbound_email" table:

SELECT DISTINCT ie.id,ie.created_by
FROM inbound_email ie
LEFT JOIN users u ON ie.created_by = u.id
WHERE u.id IS NULL;

After deactivating the corresponding inbound rules by setting the "deleted"-flag to "1" in inbound_email-table, the code could be removed from the PHP file and editing the user objects is now possible and the Inbound rules are displayed correctly.

Possible Fix

No response

Steps to Reproduce the Issue

As far as we know, it should be reproducible this way. However, the instance is only used for update testing, so the following is only theoretical:

1. Create User
2. Create inbound account with the new user
3. Delete user (completely from database, not only the "deleted"-flag), so that the user does not exist in table users anymore.
4. Try to open the inbound-rules

Context

No response

Version

8.8.0

What browser are you currently using?

Firefox

Browser Version

No response

Environment Information

10.11.11-MariaDB

Operating System and Version

Debian 12

Originally created by @brunt82 on GitHub (May 26, 2025). ### Issue We recently updated our SuiteCRM instance from 7.14.6 to 8.8.0. We're now experiencing the following error (although it may have already existed in 7.14): When we try to edit a user or open the email inbound settings, a blank page appears, and the browser logs an HTTP-500 error. The following stack trace appears in the Apache log: > [Mon May 26 11:08:58.338957 2025] [php:error] [pid 117641:tid 117641] [client 10.161.0.4:55641] PHP Fatal error: Uncaught Error: Call to a member function getPreference() on bool in /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php:6953\nStack trace:\n#0 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(6887): InboundEmail->calculateSignature()\n#1 /opt/SuiteCRM-8.8.0/public/legacy/data/SugarBean.php(4752): InboundEmail->fill_in_additional_detail_fields()\n#2 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(381): SugarBean->retrieve()\n#3 /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php(6704): InboundEmail->retrieve()\n#4 /opt/SuiteCRM-8.8.0/public/legacy/modules/Emails/EmailUI.php(1371): InboundEmail->retrieveAllByGroupId()\n#5 /opt/SuiteCRM-8.8.0/public/legacy/modules/Emails/EmailUI.php(298): EmailUI->getMailboxNodes()\n#6 /opt/SuiteCRM-8.8.0/public/legacy/modules/Users/views/view.edit.php(296): EmailUI->displayEmailFrame()\n#7 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/View/SugarView.php(210): UsersViewEdit->display()\n#8 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/Controller/SugarController.php(434): SugarView->process()\n#9 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/Controller/SugarController.php(365): SugarController->processView()\n#10 /opt/SuiteCRM-8.8.0/public/legacy/include/MVC/SugarApplication.php(101): SugarController->execute()\n#11 /opt/SuiteCRM-8.8.0/public/legacy/index.php(52): SugarApplication->execute()\n#12 {main}\n thrown in /opt/SuiteCRM-8.8.0/public/legacy/modules/InboundEmail/InboundEmail.php on line 6953, referer: https://suitecrm-test-ng.domain.de/ By adding the following lines of code in **public function calculateSignature()** we work around the problem: ``` if (!$owner || !($owner instanceof User)) { if (isset($GLOBALS['log'])) { $GLOBALS['log']->fatal("calculateSignature: Benutzer mit ID '$createdBy' konnte nicht geladen werden."); } return; } ``` Thanks to the additional log line, we were able to determine that the retrieved user IDs actually no longer exist in the database. The user IDs can be found in the "created by" column of the "inbound_email" table: ``` SELECT DISTINCT ie.id,ie.created_by FROM inbound_email ie LEFT JOIN users u ON ie.created_by = u.id WHERE u.id IS NULL; ``` After deactivating the corresponding inbound rules by setting the "deleted"-flag to "1" in inbound_email-table, the code could be removed from the PHP file and editing the user objects is now possible and the Inbound rules are displayed correctly. ### Possible Fix _No response_ ### Steps to Reproduce the Issue ```bash As far as we know, it should be reproducible this way. However, the instance is only used for update testing, so the following is only theoretical: 1. Create User 2. Create inbound account with the new user 3. Delete user (completely from database, not only the "deleted"-flag), so that the user does not exist in table users anymore. 4. Try to open the inbound-rules ``` ### Context _No response_ ### Version 8.8.0 ### What browser are you currently using? Firefox ### Browser Version _No response_ ### Environment Information 10.11.11-MariaDB ### Operating System and Version Debian 12

deekerman added the

labels

2026-02-20 16:59:38 -05:00

deekerman commented

2026-02-20 16:59:40 -05:00

Author

Owner

@brunt82 commented on GitHub (May 26, 2025):

Sorry, seems that I created the issue in the wrong queue? Maybe SuiteCRM-Core fits it better?

@brunt82 commented on GitHub (May 26, 2025): Sorry, seems that I created the issue in the wrong queue? Maybe [SuiteCRM-Core](https://github.com/salesagility/SuiteCRM-Core) fits it better?

deekerman commented

2026-02-20 16:59:40 -05:00

Author

Owner

@johnM2401 commented on GitHub (May 26, 2025):

Hey!

Thank you for raising this, I'm happy to keep this in the current "SuiteCRM" repo as I've been able to reproduce this on 7.14.6 too.

As it is replicable on both versions, if a fix is merged for this on the SuiteCRM branch, it will also be pulled into a subsequent SuiteCRM8 release.

Thank you again!

@johnM2401 commented on GitHub (May 26, 2025): Hey! Thank you for raising this, I'm happy to keep this in the current "SuiteCRM" repo as I've been able to reproduce this on 7.14.6 too. As it is replicable on both versions, if a fix is merged for this on the SuiteCRM branch, it will also be pulled into a subsequent SuiteCRM8 release. Thank you again!