Suitecrm: trimTracker() SchedulerJob fail after update 7.11.12

[holdusback]

Hey there, since it run only on the 1st of each month, I discovered the monday that this job fail after 7.11.12 update (It worked great last month without any error)

I had this error in suitecrm log file :
Job (PruneDatabase) failed in CRON run.

After a lot of re search, I tried :
To delete manually the tracker table.
Re build Scheduler Job.
Stop all other job.
Checked my DB, its not so big, tracker table had something like 400 lines ...

I put some log in modules/Schedulers/_AddJobsHere.php in trimTracker(), after some debug I checked my CRM before 7.11.12 and this line change :

$timeStamp = DBManager::convert("'" . $timedate->asDb($timedate->getNow()->get("-" . $prune_interval . " days")) . "'", "datetime");

I changed it back to the previous version :
$timeStamp = db_convert("'" . $timedate->asDb($timedate->getNow()->get("-" . $prune_interval . " days")) . "'", "datetime");

Now the job run successfully, like before. So its this change from the 7.11.12 update that cause the fail.

Latest Chrome version
SuiteCRM v7.11.12

[Mausino]

It will have something with Part 3 #7806

But for part 3 ins't yet created any pull request and don't know if the pull request from part 1 & 2 can be implemented for "DBManager::convert" @Jason-Dang

[holdusback]

Doesnt really understand the point of the PR 7806... But has I saw they merged only part 1 and you say its part of part 3 of theyre big change ?

[Mac-Rae]

Just to confirm neither #7795 or #7806 made it into the current release. Our releases are build from the branches which have the -CF or -cf tag on the end. These stand for code freeze and are frozen to new merges in advance of the release, therefore, anything merged after this point will go into a future release allowing for additional work and testing to take place :+1:

[holdusback]

Does this mean that 7.11.13 will fix this issue ?

[Mac-Rae]

I don't think it would, altho I've not looked into this issue yet. From what I can see this is the PR which made the changes - #8129

I'll try to take a look at this today when I get the chance

[Mac-Rae]

8577 appears to be caused by the same change, tagging for reference

[Jason-Dang]

@Mausino As per @Mac-Rae's update, those two PR's weren't included in latest release, though I don't think they would have impacted this area if they were.

@holdusback Apologies the descriptions may not be so clear.

Part 1 changes the BeanFactory to enable extending of core module classes in a non-breaking way: CustomAccount extends Account and so on (Previously attempting this broke the system). It also dynamically loads the needed files so you don't have to include/require them yourself.

Part 2 is strictly about improving BeanFactory coverage so that module classes are loaded through the BeanFactory instead of directly, thus improving support for customisations across the board. This done deals with explicit instantiations of classes specifically; changing things like: new Account, to: BeanFactory::newBean('Accounts').

Part 3 is about the same thing, except it's dynamic instantiations (less of these but a little trickier to deal with across the board); changing things like: new $className(), to: BeanFactory::newBean($moduleName). Note that $className and $moduleName
are inconsistent and may differ. $className represents the actual class name in this example while $moduleName is the key to the whole shebang and required by the BeanFactory to map everything (i.e. Module Name: Accounts | Class Name: Account).

Part 4 is slightly decoupled in that, it changes usages of the module name converted to lower case as the module's table name which IMO is a bit silly. It's possible to get this from a bean object itself or from BeanFactory helper methods. The actual table name property that is used, can potentially differ from the module name entirely (i.e. custom modules and extended core modules).

Hope the above clears things up with those PRs and their changes/point?

[holdusback]

Thanks a lot for the big comment ! you should def c/c this do your original PR for the others that may need more info about it ! 😁

[Mac-Rae]

Hi @holdusback and others,

This issue has been confirmed to exist and is replicable in the latest 7.10.x version.

Thanks :+1:

[Obiwanbde]

Same for me with clean installation of 7.11.12 before 1st of March and started to get this error. I have reverted to db_convert as @holdusback said at first and it has worked(scheduler shows last successful run date which was "Never" before) though do not see any decrease in tracker table.