Jeremy Davis's picture

Could you please provide a little more detail on how we can reproduce the issues that you've experienced? If we can reproduce it, we should be able to fix it. We can then document a workaround, with an aim to release a fixed appliance ASAP.

Also FWIW, we recently had a bug report related to issues logging in as admin. I wonder if they're at all related?

Hi Jeremy - It appears the main body of my message did not actually get posted because I am not seeing it in this thread and just see  your reply asking for more information. I saw a posting a few days ago about other people having problems with their posts or comments showing up.

I will provide detailed information below. It appears to be fixed now. It looks like there are 3 issues: 1) it was a cache problem, 2) problem with emailAddressReplyToFlag, and 3) there appears to be a problem with the user:group settings for the SuiteCRM files and folders. I hired someone to help me troubleshoot and I will provide you the information  below for this site's reference and if you agree this is a proper fix, then you can include it in future updates.   :)

I have been using Turnkey SuiteCRM for about 2 years. It has been working well. I want to give back to the community. Thank you for all the hard work that you do.

I downloaded and installed Turnkey SuiteCRM 15.0 (SuiteCRM 7.8.20)  on a test computer. The computer is on a local network, so instead of adding a fully qualified domain name during installation, I used the IP address (192.168.99.210) and set the networking to a static IP.

 I added 1 user and 1 lead.  When I tried to update the settings either when logged in as Admin or when logged in as the user and I tried to change settings in Email settings, Password management, Profile, etc., the program acted like it was saving the changes, but when I wentback into it, most of the time it did not save the changes.  Sometimes after doing this process several times it did save the changes.  I could not get it to save allowing the "reply to" box to be checked in a user's profile.  This was very frustrating.

I coordinated the time settings for the admin and the added user but this did not seem to fix the problems.

I did have to change the permissions and user:group for the suitecrm files because some files/folders were owned by root:root and others by www-data:www-data. So I issued the commands recommended by SuiteCRM:

cd /var/www
chown -R www-data:www-data suitecrm
chmod -R 755 suitecrm
cd suitecrm
chmod -R 775 cache custom modules themes data upload config_override.ph

This still did not fix the problem.

I have been using Chrome browser.  I also tried doing some of the changes in FireFox Mozilla to see if I would get something else.  When I clicked Save in FireFox for updating a profile setting then it went to a white page that said "Bad data passed in: Return to Home"

To fix the "Reply to" checkbox being able to save in a User's profile I did the following:

1.    open the file at the path cache/include/javascript/sugar_grp_emails.js find emailAddressReplyToFlag and remove the extra double quote from emailAddressReplyToFlag 
2.    in the file that is at the path jssource/src_files/include/SugarEmailAddress/SugarEmailAddress.js do the same as in above file

To fix "Enable system generated password feature" checkbox not saving when saving system settings. This includes fixing of caching issue.

1.    Open the file /etc/php/7.0/apache2/php.ini and set opcache.revalidate_freq = 0
2.    Run the following command “service apache2 restart”

 

Jeremy Davis's picture

Thanks heaps for sharing your experience. We'll look to address the issues that you brought up in the next SuiteCRM appliance release.

Sorry to hear that the txt of your original post also got lost. I'm pretty sure I've fixed that now though. Please do not hesitate to email me direct (jeremy AT turnkeylinux.org) if you experience any weirdness with the website again.

I note that the PHP opcache setting that you have updated is not recommended on a production server. My understanding is that the opcache (which you have essentially disabled via that setting change) caches the result of processing the PHP files. This will radically speed up a production server's ability to server pages to users. It's fine on a development server as you would often wish to see the updated results of changes made to PHP files. But on a production server, the opcache cache should only be updated after PHP files have been edited/updated (which on a TurnKey LAMP based appliance such as SuiteCRM, can manually be done by restarting Apache - as you did to apply the change you made).

So whilst that may have appeared to resolve the issue in your case, I'm not 100% sure whether that's really what did it, or if that was coincidental (perhaps a result of something else you did it was actually the Apache restart that applied your changes?). So it sounds to me like that one may need some further investigation.

WRT the file permissions, our default set up is by design. Having many/most files owned by root by default means that if an attacker does manage to break into your server, then the amount of damage that they can do is significantly limited. Having said that, under some circumstance, that can cause issues, especially if there are files that the webserver needs to update but can't (which may be the case in this instance i.e. perhaps we missed a file that should be writable by the webserver?). Also when software is updated by the root user, that can sometimes cause issues.

The "Reply to" issue that you note though, does sound like something that can and should be addressed fairly easily by us at build time. We'll definitely look to address that for the next release. I'll also have a closer look at those other things as well.

Thanks again.

Add new comment