Hello Ihor, Many thanks for your swift response.
Ihor Radchenko <yanta...@posteo.net> writes: > [...] >> Does anyone recall the rationale for this different behaviour? > > The "default" behaviour is to store summary of all the child property > value in each parent. > [...] > This is, however, not possible for CLOCKSUM because clocksum is not an > actual property, but a "special" one - it is derived from logbook data. > That's why its behavior is different. I see; thanks for explaining the rationale. Practically this seems to imply that for doing estimates, and to minimise my own confusion, I should probably use a strategy where I put all the effort properties in a subtree at the same level (for instance leaf-nodes-only, or top-nodes-only). And additionally, I should never modify effort properties by hand, but using the columnview overlay only (since that will not allow me to modify efforts computed from child nodes). > In fact, CLOCKSUM property does not support custom summaries. ??? >> Is there any way to change the summation behaviour for either or both >> column types? > > It is currently hard-coded. (Although, it is not too hard add some kind > of switch). > [...] I think that instead of a switch, I would prefer the columnview dblock to get a :formatter added. Knowing how the values have been computed in the dblock's write function, I can re-calculate whatever data I need in the formatter. I am already using this approach successfully with the clocktable dblock to generate invoices for me. Compared to a new switch, it would seem to me that adding a :formatter to the columnview dblock has several advantages: - it would likely be a smaller code change; - instead of implementing a single, new behaviour (activated by switch) it would give users the flexibility to implement any new behaviour they might want (user-supplied :formatter function). Thus, from my point of view, having a :formatter for the columnview dblock would be quite fabulous. 🦄😜 Cheers, and looking forward to your thoughts, --alexander