Use of a standard logging framework would make most of this less brittle through extension. A working debugger would help make much of this moot. Ability to debug running business rule logic would put OS lightyears ahead of the CPM field from a development perspective.
Ultimately, logging should be the responsibility of the developer. If that developer is OneStream, then start there. Use a standard logging framework and establish logging practices.
Redaction where logging is our only form of debugging, may potentially cripple the development process.
I also think that OS will find that redaction is a brittle, reactive design approach - on they will be in constant maintenance of. Extend a standard framework with redaction services and make that configurable.
An alternative to redaction is to extend a logging framework with something specifies something written to the log as "Administrative" such that it doesn't get listed in the log viewer unless the user is in the Administrator group.
Logging doesn't sell the product. Use off the shelf standard frameworks, and focus on features that sell.
Couldn't agree more, Robb! Alas, no word yet that the 'feature' of redacting is going to be removed, made optional, or made at least somewhat controllable.
Besides the fact that it limits our ability to test, it also just seems arbitrary. I mentioned it before, but someone really needs to explain to me what purpose redacting of the decimal positions serves. And one, albeit repeated example, the redacting of the value of a constant called CLASSNAME, but not redacting it when I change the name to RULENAME.
All of this is secondary to your much more important point that Onestream needs a debugging/logging framework.
And while i am on it, may I add a feature to check out and check in rules, and actually every object, so that we don't overwrite each other's work. I can check out and check in a report in narrative reporting but not a rule.
