CONVERT method does not work as expected when filter is applied to Fava

[wesalvaro]

There seem to be a lot of descrepancies (i.e. problems) with how Fava does unit conversions when compared to Beancount/bean-query. In this bug, we focus on how querying inside of Fava breaks when filters are applied in Fava.

Steps to reproduce

1. Start Fava
2. Run a query without a CONVERT in it:

   SELECT SUM(COST(POSITION))
   sum_cost_position
   3946982 IDR
   24004 JPY
   -1889 MYR
   9.34 USD

3. Add a wrapping CONVERT to it:

   SELECT CONVERT(SUM(COST(POSITION)), "JPY")
   convert_sum_cost_position_c_
   3769 JPY

4. Select a filter in the top-right box (e.g. any tag, payee, account, etc.)
5. Notice complete change in results:

   convert_sum_cost_position_c_
   3865732 IDR
   -9036 JPY
   9.34 USD

Other notes

Filtering in the query in Fava is fine

SELECT CONVERT(SUM(COST(POSITION)),"JPY") WHERE "bali" in tags'
convert_sum_cost_position_c_
28511 JPY

bean-query my.bean 'SELECT CONVERT(SUM(COST(POSITION)), "JPY") WHERE "bali" in tags'
convert_s
---------
28511 JPY

Fava can also be off-by-one from bean-query

SELECT CONVERT(SUM(COST(POSITION)),"JPY")
convert_sum_cost_position_c_
3769 JPY

bean-query my.bean 'SELECT CONVERT(SUM(COST(POSITION)), "JPY")'
convert_
--------
3768 JPY

Some date filters seem to work while others do not?

Selecting filter 2023 in my case yields:

convert_sum_cost_position_c_
2922 JPY

While selecting filter 2020 yields:

convert_sum_cost_position_c_
-27 MYR

[yagebu]

When filtering, Fava runs the query on the filtered list of entries - so it is quite expected that the output changes when the filter changes. For most other reports, the filtering has no impact on the price conversions, since we always use the price map that was built from all the prices. However, to the Beancount functions that we currently use we can not separately pass a price map, so if most prices are filtered out, the result will change as you observed.

For account, tag, payee filters, I believe filtering out the prices is not ideal, those filters could be adjusted. For the time filter, I'm not quite sure yet whether we should change the behaviour (if I currently filter to 2022, conversion will also only consider prices from 2022 - that might be a useful behaviour for some queries).