This fixes a major flaw in the history API that was causing "phantom" CMDBChange records (without any CMDBChangeOp attached). That was happening especially in iProcess impl.
For example this lead to the creation of the combodo-cmdbchange-cleaner module in the Mail To Ticket extension.
The modifications in detail :
- We can now pass a non persisted CMDBChange instance to \CMDBObject::SetCurrentChange
- No persistence done in \CMDBObject::CreateChange anymore
- Persistence of the attached CMDChange will be done if necessary in CMDBChangeOp::OnInsert
- New CMDBObject::SetCurrentChangeFromParams helper method to ease resetting the current change
* Remove XFrame header set in \WebPage::no_cache : not this method responsability, was confusing :/
* Remove no_cache() calls when already set in page constructor (ajax_page mainly)
* Also calls everywhere the \WebPage::no_cache method instead of setting headers manually
It is quite common that the PHP interpreter that is launched in CLI is different that the one used by the webserver. So iTop code launched by CLI could run in a context that doesn't meet iTop requirements !
This adds in the following scripts the same control that is done on the setup wizard first step :
* cron.php
* backup, check-backup
* export, exportv2
* bulk import
* synchro-exec, synchro-import
If the check throws at least one error then the script is stopped with an appropriate message, and a log is made (IssueLog, Error level, CLI channel)
Previous commit : 24eb82d1
Use \CMDBObject::SetTrackInfo
Move \CMDBObject::SetCurrentChange calls at the top most level of the stacks
Restore old behaviors that were removed in previous commit
* 📝 little PHPDoc in BackupExec
* ♻️ Create a extendable implementation of iScheduledProcess
* create AbstractWeeklyScheduledProcess
* move schedule methods to the new abstract class
* create ProcessInvalidConfigException
* in cron.php skip abstract class
- bootstrap.inc.php is now included by approot.inc.php
- remove all unescessaries includes of bootstrap.inc.php
- in bootstrap.inc.php autoload can be bypassed using a feature flag because "why not"
* starting a new transaction will send nothing in the DB (only one global transaction : merge nested transactions)
* same for COMMIT or ROLLBACK if more than 1 transaction is opened
* transactions are kept inside \DBObject::DBInsertNoReload, but they can be disabled using config flag db_core_transactions_enabled=false (true by default, hidden by default)
