search

gristlabs / grist-core

Grist is the evolution of spreadsheets.
https://www.getgrist.com/
Apache License 2.0
6.96k stars 306 forks source link

Columns in different summary tables with same name affect each other #361

Open acw1251 opened 1 year ago

acw1251 commented 1 year ago

I'm not sure if this is a bug report or an improvement suggestion because I don't know if this behavior is intended or not.

To reproduce from a new document: 1) Add a row to the default table with some dummy data. 2) Make two summary tables, one grouping by column A and one grouping by column B. 3) Add column Foo to summary table A and set the formula to =1. 4) Add column Foo to summary table B. At this point the newly added Foo column will be empty. If you set the formula for the newly added Foo to =2, this will also change the formula for the other Foo column to be =2 too. 5) Bonus: Rename Foo in either summary table. It will change the name of both columns.

If this is intended behavior, then when Foo is added to summary table B in step 4 above, I think it would be best for it to appear with the formula from summary table A already in it instead of being empty.

dsagal commented 1 year ago

Hi! You are right, this is mostly intended behavior. The real intent is that if you have, say, and auto-generated formula in a summary table like SUM($group.Amount), and you change it to AVERAGE($group.Amount), then when you add another summary of the same table, or change the group-by columns, the new formula would apply consistently.

In a way, summary tables are a kind of aggregated "views" of data, so while implemented as separate Table objects, they are presented as if they were different views on the same data.

But I agree fully about your last point. To be consistent with the idea of "views", the existing column Foo (with formula =1) should be shown as available for summary table B, and should have that existing formula.

acw1251 commented 1 year ago

Thanks for the explanation. That behavior makes sense. Are you suggesting that adding Foo to summary table A adds it as a hidden column to summary table B? I think that's a nice solution since when you press the + column button, you see the hidden columns you can show just below the option to add a new column. In my example, when you are trying to add the second Foo column, you can decide whether you want it to be the same and just show the original Foo column, or you can make a new column with the Foo label, but a different internal name ($Foo2).