Done now before their as used too widely. We are most likely to allow dev. to use custom colors soon, so we want to avoid confusing / renaming then. (iTop extensions have been verified, none had to be migrated)
In 2.7.5 with N°3513 we added a second mysqli attribute in CMDBSource, so that we can test transactions (see TransactionsTest).
But this wasn't documented, and was really causing confusion !
This refactor wraps both attributes in a dedicated object so that the logic is clearer.
plus:
- the entrypoint is now `LogException()` instead of `FromException()` which sounded more like a factory and less like an active method.
- merge conflicting commit with @molkobain (CC fix)
- remove the writing of the exception object in the error.log context (adding it was an error, it's way too verbose!!).
- Technical note: The context is still used to propagate the exception across several call stack, so it now uses a less generic naming in order to avoid conflicts (see `ExceptionLog::CONTEXT_EXCEPTION`). another solution would have been to add a new parameter to `ExceptionLog::Log()`, but I didn't want to add constraint over the hypothetical evolution of the base class method.
plus:
- the exception object is no more automatically added to the error.log context (it's way too verbose)
- code cleanup (use constant instead of repeated strings)
- ExceptionLog main method is now named `LogException` instead of `FromException`
Try to repair an odd error in the CI:
> Fatal error: Uncaught Exception: Serialization of 'ReflectionClass' is not allowed
avoid instantiation in the provider, delay them to the actual test
Try to repair an odd error in the CI:
> Fatal error: Uncaught Exception: Serialization of 'ReflectionClass' is not allowed
Maybe it's triggered by the mocks being a property of the test class, so I inlined them.
+ misc. minor modification in order to try to figure out what is causing this behavior.
Such Exceptions are triggered with a Warning level and default the minimum default level in order to write in DB is above, so the behavior is not modified:
- logs are written in errors.log (with a warning elvel instead of an error)
- logs are not written in DB unless `log_level_min.write_in_db` is changed
