'Copy All Filters' Button
Hey guys, Dor here!
as you want to achieve faster results, I think the users want some faster report building!
Sometimes when we build a report, we think about whether we do an append or solve it all under the master query.
If we decided on an append, most of our reports' appends are used to show different time frames.
The population always stays the same, which means that all the filters are the same throughout the report.
We always dragged the same filters, and linked to the filters inside the master query, and it would take a lot of time.
What do you think about making a button which copies all the filters inside the master query, to the append ?
Maybe another button, that says "copy all filters and link" - so it will also link to the same filters ! :)
OR - maybe - a button, that just duplicates the master query to an append.
Which means - copy all filters, copy all headers/rows AND - design formatting, if anything has changed.
Hi Dor,
I like it, I like it!
In fact I liked it so much I turned it into an internal Enhancement Request
As always, thank you for your creative input.
regards,
David
Hi Dor,
I like it, I like it!
In fact I liked it so much I turned it into an internal Enhancement Request
As always, thank you for your creative input.
regards,
David
Hi Dor,
We're just trying to get a better understanding on this one. My question is, why not just copy a report (this way all filters are filters are copied too); or, if there are filters that will be common between several reports, why not use View-level filters? If the same filters are being used so frequently so as to make it beneficial to copy them, I'm having a hard time seeing why simply copying a report, which would presumably already have most if not all the same filters already applied, wouldn't be a workable solution. Can you please explain why these wouldn't make for good solutions in your use case(s)?
Thanks,
Mike
Hi Dor,
We're just trying to get a better understanding on this one. My question is, why not just copy a report (this way all filters are filters are copied too); or, if there are filters that will be common between several reports, why not use View-level filters? If the same filters are being used so frequently so as to make it beneficial to copy them, I'm having a hard time seeing why simply copying a report, which would presumably already have most if not all the same filters already applied, wouldn't be a workable solution. Can you please explain why these wouldn't make for good solutions in your use case(s)?
Thanks,
Mike
Hi Mike,
Think of a report where you need a few unions. For example, a recent report request required me to have to create 5 unions. The only difference in each union is the filter value for one of the non-user-prompted filters. All the other filters are linked to the master query filters. I could have saved a boatload of time by creating the first union and simply copying it four times. The only thing I would have had to change was the value of the non-user-prompted filters. I completely agree that this enhancement is highly desired! The struggle is REAL! :)
Hi Mike,
Think of a report where you need a few unions. For example, a recent report request required me to have to create 5 unions. The only difference in each union is the filter value for one of the non-user-prompted filters. All the other filters are linked to the master query filters. I could have saved a boatload of time by creating the first union and simply copying it four times. The only thing I would have had to change was the value of the non-user-prompted filters. I completely agree that this enhancement is highly desired! The struggle is REAL! :)
Hi Larry,
Thank you for your feedback. I've added your comment to our internal task for further consideration regarding this.
Regards,
Mike
Hi Larry,
Thank you for your feedback. I've added your comment to our internal task for further consideration regarding this.
Regards,
Mike
Hey Mike!
Adding to Larry's great comment - our reports are all dynamic.
We keep changing filters, there's not a single report which can be duplicated. All reports serves different purposes and departments.
And the problem we're facing is not in the master query's (MQ) level - but the appends/unions/intersects/excludes.
We have lots of reports that using multiple queries.
Every time we think of how to construct a report, most of the time we concluding the creative/productive thinking, with a need of appends to the MQ. That being said - we're always taking consideration of extra developing time because we need to create the exact same queries with the same filters applied to the MQ.
Now, imagine you have more than 10 filters. :) We have some reports with 12-13 filters. :)
Agonizing..
Hey Mike!
Adding to Larry's great comment - our reports are all dynamic.
We keep changing filters, there's not a single report which can be duplicated. All reports serves different purposes and departments.
And the problem we're facing is not in the master query's (MQ) level - but the appends/unions/intersects/excludes.
We have lots of reports that using multiple queries.
Every time we think of how to construct a report, most of the time we concluding the creative/productive thinking, with a need of appends to the MQ. That being said - we're always taking consideration of extra developing time because we need to create the exact same queries with the same filters applied to the MQ.
Now, imagine you have more than 10 filters. :) We have some reports with 12-13 filters. :)
Agonizing..
Hi Dor,
I hear you. We're just trying to get a better understanding of the use case. Thank you for supplying your reasoning here. I'll keep you posted on any future developments regarding this.
Regards,
Mike
Hi Dor,
I hear you. We're just trying to get a better understanding of the use case. Thank you for supplying your reasoning here. I'll keep you posted on any future developments regarding this.
Regards,
Mike
Replies have been locked on this page!