Calculate lookups on the front end (based on filters)

[RonMakesSystems]

I’m aware this would be a big change, but hear me out! Lets say im using the same category for task status in different places across my workspace. I want each status to show the total number of hours of tasks. The problem is that the lookup is looking at all task in all projects. I just want to see the totals for the project I’m currently on. Maybe a checkbox in the formula field to respect view filter? Or actually the way the least will break if introducing a new formula expression?

Another application is in reports. Wanting to create a report showing accounts and categories for a specific time frame. Showing the sum of transactions only from a specific filtered timeframe. While there are workarounds, they are not as pretty.

[Chr1sG]

I’m not sure I get the problem.
If you want to get the sum of hours spent on Tasks linked to a Project, can’t you just use a formula field on the Project db:
Tasks.Sum(Hours)
?

@RonMakesSystems

Another application is in reports. Wanting to create a report showing accounts and categories for a specific time frame. Showing the sum of transactions only from a specific filtered timeframe.

This is exactly how aggregation calculations work in report view: you will see the calculation for the data records which meet the filter criteria for the report view, whether that is by category or for a limited time range.

[RonMakesSystems]

And for reports:
While it can indeed be done in this way, and using the split as you’ve explained to me in the past. If it was possible to filter the lookup’s of the transactions that are being calculated to the account, it would be more intuitive I think. Let me know if it makes sense.

[helloitse]

I think this feature request is tied to the general concept of having calculations function as a part of views not as a formula field at all.
The current solution would be to create many formula fields that calculate various conditions to match a fixed set of filters. For example I have a formula that calculates the number of active sub articles in my Company manual and I display it on list views:

We’re really looking to recreate the common function in competitor tools of aggregating data about the entities in view (Sum, Avg, Count).
There’ve been several requests through the years that relate

Formula fields that are filtered by the context they're viewed in

Aggregations by row/column in board view would likely cover many of the situations I’m thinking of. My only issue with aggregations on table view is that they can’t be filtered. Here’s a request I made a few weeks back about it: Allow specific databases to be excluded from column calculations I usually default to formula improvements being an ideal solution because the more they get improved the more flexibility and autonomy all your users have to customize their workspaces themselves without …

Kanban view columns & formulas

Hey guys, Not sure if doable or not but would it be possible to allow defining custom formulas allowing to compute specific indicator based on Kanban columns content? Computed value could be located under the column title (close to the count information when displayed). [image] Cheers.

Which is also linked to Kanban board details - WIP Limits

Fibery makes us choose between views which allow us to edit and interact with the entities, and reports which aggregate information about the entities and their properties. This is a hard transition when coming from other tools which do not offer powerful reports and so have lightweight aggregations inside the views. I think there are clearly many cases for why in-view calculations should be functions of the view and not a part of the data model.

[Chr1sG]

Is this basically the same thing?

In other words, the ability to have aggregate calculations in views other than table view…

[RonMakesSystems]

Yes, I see now this was asked already. Sorry making duplicates. Essentially yes, aggregating in other views. I ask it like this because the formulas / lookups are usually used to aggregate at the moment. But I also feel that adding aggregation to other views would be less powerful and more restricting than changing formulas to calculate in the front end. Feel free to merge this with the other one.