Custom AOR_Reports


I’ve made a customization to the aor_utils.php script in the suitecrm/modules/AOR_Reports directory and my change is picked up after a Quick R&R. To make is upgrade safe I made a directory AOR_Reports in custom/module, set the permissions the same as the original, and placed my updated aor_utils.php script there. I then reverted the original suitecrm/modules/AOR_Reports/aor_utils.php back to the out of the box file. My custom aor_utils.php is not getting picked up and used. Do I need something else to have a custom AOR_Reports directory?


If a customizations isn’t getting picked normally it’s because some other file invoking it is not ready for this customization process. So the workaround is to customize that previous file also.

In your case, I would start by searching for references to that file:

/var/www/html/modules/AOR_Reports/Dashlets/AORReportsDashlet/AORReportsDashlet.php:8:require_once 'modules/AOR_Reports/aor_utils.php';

/var/www/html/modules/AOR_Reports/views/view.edit.php:28:require_once 'modules/AOR_Reports/aor_utils.php';

/var/www/html/modules/AOR_Reports/views/view.detail.php:27:require_once 'modules/AOR_Reports/aor_utils.php';

/var/www/html/modules/AOR_Reports/AOR_Report.php:72:        require_once('modules/AOR_Reports/aor_utils.php');


Now you can customize all those files (or only the one that matters to you), copying them to the custom directory, and changing those require_once commands like this:


Tell me if this works, I guess I can make Pull Request making this change definitive in the main product. It’s better if the customization process is respected consistently everywhere.

Definitely agreed with your point. If the Customization is also considered for aow_utils.php file, it will help upgrade safe changes for all the custom fields that we use.

How does this look?

Can any of you guys test this? Checkout this branch on top of your test installation and run a few tests in the Reports and Workflows module?

The changes looks good to me, just checked each file individually.

“looks good” is not the same as “I tested it and it works”. :slight_smile:

My apologies - what is the easiest way for me to check this out on my test installation? I have a test suitecrm running. But not sure how to download these files to it. I get checkout the branch but wouldn’t that mean I’d have to cloned the project to start with, then do a checkout? Is there a way I can just get the files and drop them into my current test system?


Ok, I’m not very sure of this - git is always a tricky thing to get right. But I’m sure there is a way (those “–force” flags can do miracles).

Make sure you have a backup of the directory before starting, even if it’s just a test server, so that you have an easy way to go back and restart if things get messy.

Make sure the versions match (this will be easier if you are on 7.9.2)

Then maybe some combination of this, in the SuiteCRM root directory:

git init
git remote add patchRepo
git fetch patchRepo patch-AOR-custom
git checkout patch-AOR-custom

Now, I’ve never done this, and I’m guessing this last command might give some error message, or not work.

Then you must use all your git-fu powers, and when they run out, turn to the great git-master (Google), which will give you stuff like this
and much more.

If you get an error message in the checkout, try Googling that error.

Good luck… and thanks for trying.

1 Like

The changes worked for my use case.

I need to have a period of Next Week for running a report that contains a condition on a date field. I updated the dropdown and added the code to aor_utils to make this happen. I then placed the files you altered in their appropriate directories and my custom aor_utils was picked up successfully. I’m not working with aow_utils so didn’t have any use cases to test against that.

Thank you,

1 Like