No Report Headers in Edit Mode for Reports

šŸ’¬ General Discussion
1

Just upgraded to 7.10.25 and I get ā€œundefinedā€ column headers when editing the columns or the filters. The front end of the report looks fine.

Iā€™ve tried the normal stuff like

  1. Cleared browser cache
  2. Repair and rebuild
  3. reset file permissions
  4. different combos of 1,2, &3 above

Anyone else experiencing this or is it unique to me? Any other ideas. Typically when experiencing this in the past, re-setting file permissions sorts it out.

undefined
undefined1134Ɨ320 29.8 KB

2

Try the other repairs - relationships, javsacript, etc

3

Hi Paul, I know this is an old post, but Iā€™m having this exact issue. Did you resolve this? and if so, can you remember how?

Thanks
Terry

PS: Your Youtube videos have been very helpful, thank you.

4

It ended up being a file ownership issue. I reset the permissions AND file ownership and that cleared it up.

Also, if I recall if you have SuiteCRM installed in a subdirectory like /crm I seem to remember an .htaccess issue that I had to sort out once. (I think I may have done the repair .htaccess option in Admin).

5

Thanks Paul, went through the permissions settings again ā€¦

sudo chown -R www-data:www-data .
sudo chmod -R 755 .
sudo chmod -R 775 cache custom modules themes data upload
sudo chmod 775 config_override.php 2>/dev/null

and all seems to be ok so far. Donā€™t quite understand how these permissions keep getting messed up.
Oh well! It seems to be par for the course.

Thanks Terry

6

No, permissions getting messed up is not normal, although many people have given up on understanding why it happens :slight_smile:

Reasons why permissions/ownerships change:

  1. Your cron jobs are running as a different user (typically, root)
  2. You log in with a different user and edit files.
  3. Your default_permissions in config.php are wrong
  4. Other processes running under other users mess with files
7

Thanks @pgr, good to know the root cause. Mostly your #3 fixes it for me on an ongoing basis. I rarely have the issue anymore, except sometimes when installed in a subdirectory or after an upgrade. My common practise now is to just automatically reset permissions after every upgrade. Havenā€™t had an issue in a while.

8

Thanks @pgr , I would like to understand why it happens, so your list is helpful;

1. Your cron jobs are running as a different user (typically, root)
My SCRM is running on a hosted server (cpanel), with the following in CRON settings;
/usr/local/bin/php /home1/#user#/public_html/crm/cron.php > /dev/null 2>&1
Iā€™m not sure how to check what user this is running as but I would have assumed ā€˜#user#ā€™.

2. You log in with a different user and edit files.
Not likely as I am the only user :slight_smile:

3. Your default_permissions in config.php are wrong
My settings areā€¦
ā€˜dir_modeā€™ => 1528,
ā€˜file_modeā€™ => 493, (I have seen many post of different settings here, including 420)
ā€˜userā€™ => ā€˜#user#ā€™, (I know these to be correct - obviously not #user# & #grp# !)
ā€˜groupā€™ => ā€˜#grp#ā€™,

4. Other processes running under other users mess with files
No other users, so should be all good here.

Any suggestions are most appreciated.

Thanks
Terry

9

Terry

I guess I didnā€™t explain the ā€œsame userā€ thing well enough. SuiteCRM runs from your web server, and your web server runs under a certain user. In systems you install (Ubuntu etc) this is typically a system-user account, NOT the same person-user that you use to login. So all the typical problems stem from this: person-users doing things manually break the ownerships of that system-user.

To find out which user your web server is running under, check in Admin / Schedulers, the crontab instructions on the bottom contain the user name (specific to your system).