starred/SuiteCRM-SuiteCRM

Fork 0

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

User turned on "Show Full Namtes" option in his profile and saved, but the option was turned off during the process of logging out and re-logging in. #4647

New issue

Open

opened 2026-02-20 16:21:15 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 16:21:15 -05:00

Owner

Originally created by @nwh-nwh on GitHub (Nov 6, 2021).

Issue
User successfully turned on and saved the "Show Full Names" option in his profile. User logged out and re-logged in. The "Show Full Names" option became turned-off.

Expected Behavior
The "Show Full Names" option should remain turned on, the same as what was saved in the user profile prior to his logout.

Actual Behavior
The "Show Full Names" option was turned off when the user logged out and re-logged in.

Steps to Reproduce

Log on to SuiteCRM and edits your own user profile
Turn on the "Show Full Names" option and save the profile
Double-check from the detail view of the profile that the "Show Full Names" option is indeed turned on; View other records like Accounts, Quotes, etc., to verify that full names are displayed in place of username
Log out from SuiteCRM
Re-login to SuiteCRM and view records like Accounts, Quotes, etc., they are just showing usernames and not full names. Check the user profile. The "Show Full Names" option has been turned off;

Environment
SuiteCRM v7.11.22, Apache 2.4.46, MariaDB 10.4.14, PHP 7.3.21 on Windows 10;

Further observations
Immediately after step 2, I checked the 'user_preference' table. The decoded "contents" column of the record (with "category" column = global) associated with the user contains: s:14:"use_real_names";s:2:"on";

Immediately after step 4, I checked the 'user_preference' table again. The decoded "contents" column of the record (with "category" column = global) associated with the user contains: s:14:"use_real_names";s:3:"off";

If, instead of logging out from SuiteCRM in step 4, the user just closed the browser and cleared cache, the 'user_preference' record (with "category" column = global) associated with the user remained unchanged. However, once the user re-logged in, the 'user_preference' record (with "category" column = global) associated with the user was once again altered, and the decoded "contents" column contains: s:14:"use_real_names";s:3:"off";

Thanks.

Originally created by @nwh-nwh on GitHub (Nov 6, 2021). Issue User successfully turned on and saved the "Show Full Names" option in his profile. User logged out and re-logged in. The "Show Full Names" option became turned-off. Expected Behavior The "Show Full Names" option should remain turned on, the same as what was saved in the user profile prior to his logout. Actual Behavior The "Show Full Names" option was turned off when the user logged out and re-logged in. Steps to Reproduce 1. Log on to SuiteCRM and edits your own user profile 2. Turn on the "Show Full Names" option and save the profile 3. Double-check from the detail view of the profile that the "Show Full Names" option is indeed turned on; View other records like Accounts, Quotes, etc., to verify that full names are displayed in place of username 4. Log out from SuiteCRM 5. Re-login to SuiteCRM and view records like Accounts, Quotes, etc., they are just showing usernames and not full names. Check the user profile. The "Show Full Names" option has been turned off; Environment SuiteCRM v7.11.22, Apache 2.4.46, MariaDB 10.4.14, PHP 7.3.21 on Windows 10; Further observations Immediately after step 2, I checked the 'user_preference' table. The decoded "contents" column of the record (with "category" column = global) associated with the user contains: s:14:"use_real_names";s:2:"on"; Immediately after step 4, I checked the 'user_preference' table again. The decoded "contents" column of the record (with "category" column = global) associated with the user contains: s:14:"use_real_names";s:3:"off"; If, instead of logging out from SuiteCRM in step 4, the user just closed the browser and cleared cache, the 'user_preference' record (with "category" column = global) associated with the user remained unchanged. However, once the user re-logged in, the 'user_preference' record (with "category" column = global) associated with the user was once again altered, and the decoded "contents" column contains: s:14:"use_real_names";s:3:"off"; Thanks.

deekerman added the

Type: Bug

Priority:Important

Severity: Moderate

labels

2026-02-20 16:21:15 -05:00

deekerman commented

2026-02-20 16:21:17 -05:00

Author

Owner

@nwh-nwh commented on GitHub (Nov 8, 2021):

I have just upgraded to SuiteCRM v7.12 and tested. The issue still exists. Thanks.

@nwh-nwh commented on GitHub (Nov 8, 2021): I have just upgraded to SuiteCRM v7.12 and tested. The issue still exists. Thanks.

deekerman commented

2026-02-20 16:21:17 -05:00

Author

Owner

@johnM2401 commented on GitHub (Nov 9, 2021):

Hey there,

I've given this a try in both 7.11.22 and 7.12.0, but I cannot seem to replicate this, I'm afraid

Do you know if this issue occurs for specific users? (or user types, such as Administrators)

Do you know if your CRM has any customizations around the Users table, or the Login/Logout functionality, that may cause issues? (Plugins / Logic Hooks / Workflows / etc)

Any additional info is appreciated!

Thanks!

@johnM2401 commented on GitHub (Nov 9, 2021): Hey there, I've given this a try in both 7.11.22 and 7.12.0, but I cannot seem to replicate this, I'm afraid Do you know if this issue occurs for specific users? (or user types, such as Administrators) Do you know if your CRM has any customizations around the Users table, or the Login/Logout functionality, that may cause issues? (Plugins / Logic Hooks / Workflows / etc) Any additional info is appreciated! Thanks!

deekerman commented

2026-02-20 16:21:17 -05:00

Author

Owner

@nwh-nwh commented on GitHub (Nov 9, 2021):

Hi @johnM2401,
Thank you for looking at this issue. Here are my responses to your questions:

Q: Do you know if this issue occurs for specific users? (or user types, such as Administrators)
A: It occurs for both administrators and normal users

Q: Do you know if your CRM has any customizations around the Users table, or the Login/Logout functionality, that may cause issues? (Plugins / Logic Hooks / Workflows / etc)
A: Yes, I implemented logic hooks. I did suspect whether the issue has anything to do with that logic hooks. I re-looked at the code last evening, and I subsequently "brushed it off". What I implemented comes from post #14 of this thread: https://community.suitecrm.com/t/last-login-users-data/49071/14. Essentially, via studio, I created 2 custom fields in the Users module - userlastlogin_c and userlastlogout_c. Then I use the 'after_login' and 'before_logout' logic hooks to populate these 2 custom fields:

content of /custom/Extension/modules/Users/Ext/LogicHooks/usersLH_cstmfields_defintion.php:
<?php $hook_array['after_login'][] = Array( 1, 'usersLH_cstmfields_login', 'custom/modules/Users/usersLH_cstmfields_function.php', 'usersLH_cstmfields_login_class', 'usersLH_cstmfields_login_function' ); $hook_array['before_logout'][] = Array( 1, 'usersLH_cstmfields_logout', 'custom/modules/Users/usersLH_cstmfields_function.php', 'usersLH_cstmfields_logout_class', 'usersLH_cstmfields_logout_function' ); ?>

content of /custom/modules/Users/usersLH_cstmfields_function.php:
`<?php
if (!defined('sugarEntry') ||!sugarEntry) die('Not A Valid Entry Point');

class usersLH_cstmfields_login_class {
function usersLH_cstmfields_login_function($bean, $event, $arguments) {
global $timedate;
$bean->userlastlogin_c = $timedate->nowDb();
$bean->save();
}
}

class usersLH_cstmfields_logout_class {
function usersLH_cstmfields_logout_function($bean, $event, $arguments) {
global $timedate;
$bean->userlastlogout_c = $timedate->nowDb();
$bean->save();
}
}
?>`

As mentioned previously, by viewing the above codes, I thought these logic hooks were "innocent", and so I delayed the idea of removing the logic hooks to test out.

Please let me know if you spot any fishy, and advice me if you need me to test out anything. Thank you very much!

@nwh-nwh commented on GitHub (Nov 9, 2021): Hi @johnM2401, Thank you for looking at this issue. Here are my responses to your questions: Q: Do you know if this issue occurs for specific users? (or user types, such as Administrators) A: It occurs for both administrators and normal users Q: Do you know if your CRM has any customizations around the Users table, or the Login/Logout functionality, that may cause issues? (Plugins / Logic Hooks / Workflows / etc) A: Yes, I implemented logic hooks. I did suspect whether the issue has anything to do with that logic hooks. I re-looked at the code last evening, and I subsequently "brushed it off". What I implemented comes from post #14 of this thread: https://community.suitecrm.com/t/last-login-users-data/49071/14. Essentially, via studio, I created 2 custom fields in the Users module - userlastlogin_c and userlastlogout_c. Then I use the 'after_login' and 'before_logout' logic hooks to populate these 2 custom fields: content of /custom/Extension/modules/Users/Ext/LogicHooks/usersLH_cstmfields_defintion.php: `<?php $hook_array['after_login'][] = Array( 1, 'usersLH_cstmfields_login', 'custom/modules/Users/usersLH_cstmfields_function.php', 'usersLH_cstmfields_login_class', 'usersLH_cstmfields_login_function' ); $hook_array['before_logout'][] = Array( 1, 'usersLH_cstmfields_logout', 'custom/modules/Users/usersLH_cstmfields_function.php', 'usersLH_cstmfields_logout_class', 'usersLH_cstmfields_logout_function' ); ?>` content of /custom/modules/Users/usersLH_cstmfields_function.php: `<?php if (!defined('sugarEntry') ||!sugarEntry) die('Not A Valid Entry Point'); class usersLH_cstmfields_login_class { function usersLH_cstmfields_login_function($bean, $event, $arguments) { global $timedate; $bean->userlastlogin_c = $timedate->nowDb(); $bean->save(); } } class usersLH_cstmfields_logout_class { function usersLH_cstmfields_logout_function($bean, $event, $arguments) { global $timedate; $bean->userlastlogout_c = $timedate->nowDb(); $bean->save(); } } ?>` As mentioned previously, by viewing the above codes, I thought these logic hooks were "innocent", and so I delayed the idea of removing the logic hooks to test out. Please let me know if you spot any fishy, and advice me if you need me to test out anything. Thank you very much!

deekerman commented

2026-02-20 16:21:18 -05:00

Author

Owner

@nwh-nwh commented on GitHub (Nov 12, 2021):

Hi @johnM2401,
I progressively traced and I managed to narrow down to the exact lines of code that were responsible for "flipping" the "Show Full Names" option from "on" to "off"

Here is the flow:
During logout (or during login)

user signs out (or user signs in)
logic hook for 'before_logout' (or 'after_login') is triggered
the logic hook function has this line of code "$bean->save();" which invokes "public function save($check_notify = false)" within /mdoules/Users/User.php
the "public function save($check_notify = false)" has this line of code: "$this->saveFormPreferences();"
the "public function saveFormPreferences()" within /mdoules/Users/User.php has these lines of code:
if (isset($_POST['use_real_names'])) {
$this->setPreference('use_real_names', 'on', 0, 'global');
} elseif (!isset($_POST['use_real_names']) && !isset($_POST['from_dcmenu'])) {
// Make sure we're on the full form and not the QuickCreate.
$this->setPreference('use_real_names', 'off', 0, 'global');
}
for both the logout and login logic hook cases, the elseif conditions are met, and hence, the "Show Full Names" option gets turned off, regardless of user's "Show Full Names" option previously saved in his preference.

Would you accept this as a bug?

I currently bypass the issue with this modification:
if (isset($_POST['use_real_names'])) {
$this->setPreference('use_real_names', 'on', 0, 'global');
} elseif (!isset($_POST['use_real_names']) && !isset($_POST['from_dcmenu'])) {
// Make sure we're on the full form and not the QuickCreate.
if (!empty($_POST) && ($_POST['return_action'] <> 'Login')) {
//exclude the cases of save bean from logout and login logic hooks
$this->setPreference('use_real_names', 'off', 0, 'global');
}
}

Thanks!

@nwh-nwh commented on GitHub (Nov 12, 2021): Hi @johnM2401, I progressively traced and I managed to narrow down to the exact lines of code that were responsible for "flipping" the "Show Full Names" option from "on" to "off" Here is the flow: During logout (or during login) 1. user signs out (or user signs in) 2. logic hook for 'before_logout' (or 'after_login') is triggered 3. the logic hook function has this line of code "$bean->save();" which invokes "public function save($check_notify = false)" within /mdoules/Users/User.php 4. the "public function save($check_notify = false)" has this line of code: "$this->saveFormPreferences();" 5. the "public function saveFormPreferences()" within /mdoules/Users/User.php has these lines of code: if (isset($_POST['use_real_names'])) { $this->setPreference('use_real_names', 'on', 0, 'global'); } elseif (!isset($_POST['use_real_names']) && !isset($_POST['from_dcmenu'])) { // Make sure we're on the full form and not the QuickCreate. $this->setPreference('use_real_names', 'off', 0, 'global'); } 6. for both the logout and login logic hook cases, the elseif conditions are met, and hence, the "Show Full Names" option gets turned off, regardless of user's "Show Full Names" option previously saved in his preference. Would you accept this as a bug? I currently bypass the issue with this modification: if (isset($_POST['use_real_names'])) { $this->setPreference('use_real_names', 'on', 0, 'global'); } elseif (!isset($_POST['use_real_names']) && !isset($_POST['from_dcmenu'])) { // Make sure we're on the full form and not the QuickCreate. if (!empty($_POST) && ($_POST['return_action'] <> 'Login')) { //exclude the cases of save bean from logout and login logic hooks $this->setPreference('use_real_names', 'off', 0, 'global'); } } Thanks!

deekerman commented

2026-02-20 16:21:18 -05:00

Author

Owner

@johnM2401 commented on GitHub (Nov 12, 2021):

Hey @nwh-nwh

Thank you for looking into this in further depth, looks like you've likely found the culprit!

I'll mark this as a bug

However, it may be more fitting to re-title the bug to indicate that the issue occurs when logic hooks with bean->save are used

Anyways, thank you again for raising & investigating this in depth!

@johnM2401 commented on GitHub (Nov 12, 2021): Hey @nwh-nwh Thank you for looking into this in further depth, looks like you've likely found the culprit! I'll mark this as a bug However, it may be more fitting to re-title the bug to indicate that the issue occurs when logic hooks with bean->save are used Anyways, thank you again for raising & investigating this in depth!