Context:
With the new design for report, I think we can define a pattern for comparison of report fields.
Most of the time, such reports show Function fields that depends on the context and for some reports users want to be able to compare those computed fields with the same field but computed with a different context.
For example, the Balance Sheet is often compared with the Balance Sheet of the previous year.
Design:
Here is the proposed design for such feature:
- Add a new Function field with the same definition but suffixed by
_cmp
and using another getter. - The comparison getter Function is just calling the original getter but converting all context keys ending by
_cmp
by removing the_cmp
. But if thecomparison
key is not set in the context, it just returnNone
without calling the original getter (for performance). - Add to the context Model, a
comparison
boolean field and a copy of all context keys that influence the original Function field but suffixed by_cmp
. All those new fields should be invisible ifcomparison
is not checked.
Rational:
This proposal is designed to allow easy extension if the original Function field start to use more contextual keys. Because it will be just a matter to define the same new context field suffixed by _cmp
.
Also it is safe guarder because if new context field for comparison is not created then simply the original one will be used.
Finally, the comparison context fields are chosen by the developer. He can decide to not allow to change a specific field for the comparison (For example: the filter on posted move).