For the first time in a year I am actually using V8.4 in my daily work. I have Email, tasks, leads, opportunities on the dashlets and able to read, reply and create cases. It is a milestone for me. It means things are getting fixed.
7 Likes
How do you update to 8.4 without any issues? What was your previous version? and system config?
I started with v8.0 and wasted almost a year with stuff not working. I went through the upgrade process and posted topics on the instructions I used. The biggest issue found is that SuiteCRM creates folders and cache directories and does not respect the server file owner/permissions so you end up having to fix that frequently. Once the directories are created and permissions and ownerships fixed, then it seems to work well in v8.4.
There is a general sense that permissions and ownership is something users are supposed to do but that won’t work in the long run. If we can get easy forking and codespace debugging on github I believe we’ll see the code that needs fixing and that will be an enormous benefit.
Remember, when you upgrade and run repair, the upgrade will often change and modify the db to the latest schema. don’t forget that part. The upgrade doesn’t talk about that but it does check and changes the db if required. Good luck.
2 Likes
Regarding folders or files, we need to set them using Linux command?
sudo chmod 755 <file/folder path>
Will it be difficult to find out changes into DB?
Run this command it will set all your files and folders permissions correctly:
find . -type d -exec chmod 2755 {} \; && find . -type f -exec chmod 0644 {} \;
Execute on the root of the SuiteCRM folder it will apply to all files and folders recursively.
2 Likes
There are a few extra details in the official docs, here
Apart from the ownerships, the most relevant one is that “2” before the directory permissions which ensures that new files later created underneath those directories get the proper assignments, so that the permissions scheme doesn’t degrade with time. No matter what you read elsewhere, it shouldn’t.
1 Like
I’ve edited my command above to match 2755 for folders and 0644 for files (well its really still just 644 
) as per the docs. Didn’t change the rest of the command thou because it achieves the same.
The point is that if you can outline the specific requirement for file permissions in writing to a million download users then it should also be practical to code that same requirement. Asking everyone to check the “2” when it could be coded is not typical. I’m sure there is a reason but it is not explained so far. I think the developers really need a hard look at what is holding back adoption. This is one of the biggies.
It’s in the official installation instructions… not mysteriously hidden somewhere.
There is a difference between “coding it” as you say, and sysadmin work.
“coding it” means you’re restricted to what what the web server user is allowed to do. And in shared hostings, that is not a lot. Commands trying to set ownerships or permissions simply fail. Or the software might not even be able to reach that point because it gets stopped by permissions problems before it can even check permissions.
I agree with you that this is not well done, it sucks, and for some crazy reason nobody takes this seriously, and that this craps up adoption of this software. God knows I’ve tried to raise awareness, write docs, answer forum posts, make PR’s, but it’s just a swamp.
My only gripe is that people shouldn’t underestimate the complexity of this. There will be no silver bullet that makes SuiteCRM a breeze to install by non-technical people in all kinds of environments. There can only be better documentation, better logging, better diagnostics, better ways to fail (with instructions on how to fix, adapted to the specificity of the current system).
You are A+ in support and I feel the frustration. This is not your fault. You have helped people with a difficult installation problem that no other large-scale PHP program incurs. They all self-install and understand permissions and file structures without user intervention.
You have written PRs and made endless requests to the developers and many have been implemented but many like diagnostics and other help features lie for years without review or inclusion. I encourage you to stay positive and help us rally the developers to get a statistical summary of the main impediments to using Suitecrm. I will bet that the need for a sysadmin is #1. Fix that and you have something we can tell our friends about. Otherwise, I would never suggest a non-sysadmin to use the software in V8.4 status.
Developers: Take note, your support here is loyal but frustrated. It is time to take a step back and re-think the current nonsense of having non-expert users become sysadmins for installation purposes and beyond. SuiteCRM is aware of the PHP version so implement requirements for the right version. SuiteCRM is aware of the owner and file permissions so make a seamless installation a priority. Leave the rest until that’s done. Move to latest codespace on github and publish an environment that all testers can employ and assist with bugs. You will magnify your efforts by 1000 -fold if you make it accessible.
@pgr stay positive, we all appreciate your devotion and work and expertise. I’ll help as best I can.
2 Likes
I feel your pain (but not yet your relief) … 
When I read the headline, I was encouraged and hopeful that v8 was ready for prime time.
Then I read the details and immediately reversed my thinking.
I have systems working on v7 and will keep it that way - apparently for some time to come - since I know how v7 works and I am not willing to be the guinea pig on a new system that could create more support calls from my client.
Please update this post (if there is to be one) when you think v8 is truly ready for stable, prime-time application … AND … easy conversion from a vy installation.
Would be brilliant to fully solve this permissions/ownership bug for Hacktober 2023.
How? Track down each place in the code where it creates files/folders with wrong ownership and/or permissions.
Easiest way to do this? Make each file creation call, go thru the corresponding Sugar_____() function (e.g. sugar_mkdir(), sugar_createfile() etc), and make sure each sugar____() function sets the proper ownership and permission to each file/dir it creates.
What email service were you able to integrate into 8.4?
I was able to get my email from different account on my own linux server. Both send and receive. The emails appear properly in the dashlet but the subject still has the unconverted subject line in some emails. Otherwise, it seems to be working inbound and outbound and I used my server credentials. The codespace idea would be ideal to tackle a few of these easy fixes.
Here are pics of the dashlet and email page working. I note that at some point I had tried so many email configurations that the database had multiple IDs for my server. I went in and cleaned out the email server database. That helped my last problem. That may be self-induced.
