pgr
12 March 2024 10:43
21
Search for the word header
pgr
12 March 2024 13:50
22
I wish this PR would be merged and I would stop wasting my time going in circles trying to get people to figure out how to get a simple stack trace
salesagility:hotfix ← pgorod:ImprovedLogging7.14
opened 10:20PM - 26 Jan 24 UTC
> NOTE: this is the redone version of a much older PR, #8640 which has a bunch o… f comments and code reviews, in case any one wants to check for historical reasons
## Description, Motivation and Context
Adds some `config_override.php` options to get more information in the logs, specifically:
- ability to ask for richer information regarding a single error message, making it easier to focus on a specific problem
- ability to get more highly technical information without being a technical user (useful for Forums troubleshooting and gathering info from clients)
- get IDE-level stack traces, with both argument names **and values**
## Documentation preview
https://pedro--suitedocs.netlify.app/developer/logging/#_advanced_logging_configuration
## How To Test This
Please read the documentation linked above, there are many options.
An important part of the testing is confirming that **nothing changes** until we start putting options in `config_override.php`. This will make me more confident about putting the code out there :-)
For a simple run, you can test this by adding entries in your `config_override.php` such as these (all explained in the Docs page):
```php
$sugar_config['show_log_trace'] = 'One2MBeanRelationship'; // use a boolean true for all; or a string as filter
$sugar_config['show_log_trace_with_eol'] = true;
$sugar_config['show_log_trace_overview'] = true;
$sugar_config['show_log_trace_trim'] = 500;
$sugar_config['show_log_trace_source'] = 1;
```
## Answers to some valid concerns
1. This is **backwards compatible** because it does not assume any config values to be there, always uses sensible defaults, and respects the previous meaning of `$sugar_config['show_log_trace']`.
1. This code is complex, and some bug can have slipped by, but **it only runs in the cases where you select log traces**, so it's easy to turn off, and shouldn't affect production systems.
1. Some of this code impacts **performance** (lots of string operations, more file activity) but it's always opt-in: the impact only occurs when you configure it to happen.
1. This is accompanied with a **warning** in Documentation: using log traces with argument values might leave sensitive information in the system logs. Use it only temporarily for troubleshooting purposes; obfuscate the information before posting it online; double-check that your logs are only accessible to admins; delete the logs when finished troubleshooting.
## Types of changes
- [X] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
### Final checklist
- [X] My code follows the code style of this project found [here](https://docs.suitecrm.com/community/contributing-code/coding-standards/).
- [X] My change requires a change to the documentation.
- [X] I have read the [**How to Contribute**](https://docs.suitecrm.com/community/contributing-code/) guidelines.
This is my biggest frustration with the SuiteCRM project (and I have several ongoing frustrations with it… sigh)
1 Like
fab
12 March 2024 16:24
23
I added, as suggested, the instructions in config_override, but other than the warnings about the deprecated ones, there are no errors.
However I understood part of the problem, I managed to enable the creation of the record by modifying the module’s Menu file.
The problem is this statement:
$record = $_REQUEST['record'];
$module = $_REQUEST['module'];
if(ACLController::checkAccess("$module", 'edit', true))
$module_menu[]=Array("index.php?module=$module&action=EditView&return_module=$module&return_action=DetailView", $mod_strings['LNK_NEW_RECORD' ],"Create$module", "$module");
if ($_REQUEST['action'] == 'DetailView')
$module_menu[]=Array("index.php?module=$module&action=RunReport&record=$record&return_module=$module&return_action=DetailView&return_record=$record", $mod_strings['LNK_RUN_REPORT'],$module, $module);
the $_REQUEST statement contains these entries:
[action] => LogView
[module] => Configurator
[doaction] => all
[filter] =>
so both module and record are missing, as for $module I replaced it with the module name, but I can’t recover the record ID. Maybe the $_REQUEST statement has changed in suitecrm8, I tried to use $_SESSION, but I can’t recover it either.