OneStream EmployeeI hear you, I agree that we went a bit overboard with this feature. It gets triggered in "interesting" cases, like when a string has 8 consecutive zeros... It can be maddening.
Future releases will likely dial it down a bit.
Thanks Jack,
The new feature redacts this name of a business rule "WsasDataManagementStep", or this name of a function "LoadMarketLookUpDictionary". English is not my first language, but I cannot find anything wrong with these names and i built 'Clean up words' algorithms before.
But anyway, I would hope that we get a hotfix quickly as the current feature pretty much renders logging useless. And I have to admit that i find it difficult to believe that one would log anything that is sensitive when i can right click on any cubeview that might show sensitive financial information and export to Excel. Or is Version 9.0 also redacting when exporting to Excel.
On a side note Jack, great presentation on Dynamic Cubes on Wednesday.
Hi Jack,
It would be nice if admins could choose if they want to apply this feature into their apps or not.
There are some use cases which require to see the values in the error log. And yes, there are some workarounds such as applying formatting and adapting your number, but still, you would need to start testing which formatting adaptations you need to make to your variable for each and every variable you need to see.
Thank you!
I could not agree more with fchaves. Debugging is difficult at best with this new 'feature'. And I really dont see a reason for some redacting applied. If i call a rule name variable CLASSNAME it is redacted, if i rename the variable to RULENAME it is not redacted. If i want to show a GUID part of the GUID is redacted. On amounts in the log the feature redacts the decimals.
I need this turned off now. No one asked for this "Feature". This waste so much of time and limits customer adoption.
OneStream EmployeeA workaround i've found recently is, whenever i see a [REDACTED] triggered, i make sure to concatenate that value with some arbitrary other bit (e.g. "s_" + myVariable) and then place it in the details of the error, not the subject (e.g. BRApi.ErrorLog.LogMessage(si, "check details", "s_" + myVariable) ). That seems to keep the censoring algorithm at bay.
Awesome, thanks for the tip Jack! Will try it immediately.
