Justin Schneider

Confirmed this is fixed in ART 7. Thanks!

On all recent versions of ART (since 5.5), Column Filters in Tabular reports do not move or get removed as columns are selected and deselected. Example in pictures: -1st attached image shows the report normally with a filter for col 2 with value '2'. -2nd attached image shows when col 2 is deselected, the filter stays but is shown on col 3, despite col 3 value not being '2'. There is also now an empty third column at the end. Is there any way to make it so that the filters are only shown when the...

We use ART as a way to view our common set of report stored procedures that are being distributed via executable installers to multiple network-edge databases. Since we are deploying our databases and procedures in various edge locations, we try to maintain an ART import file and recommend users of our hardware and software services spin up an ART instance for ease of viewing/accessing SQL reports about our hardware/service performance. ART imports make it very easy to import the ART config to view...

With those 2 things in mind: The easiest solution might be instead of using REPORT ID as the xml element that tells the Dashboard: Gridstack what to run, we can use REPORT NAME, since names are guaranteed unique by the current rules of saving a report? That or maybe we need to rethink how the export functions, maybe such that we have some sort of recursive tree that starts from the lowest building block LOV report, then imports the parameter(s) that uses it, then builds the Report(s) that uses the...

Using ART 6.14, I have noticed that "dashboard: gridstack" style reports, when imported, have potentially invalid Report ID XML values inside them. Steps to reproduce as administrator level user: 1. Have any 2 reports already existing 2. Go to Self-Service --> Dashboards 3. Put both reports into the Dashboard 4. Click Save in upper left corner 5. Move to Configure --> Reports page, and export both reports and the newly saved dashboard report. 6. Clear out your art instance then reimport the file....

Ok, yeah I see it. This takes care of the the columns portion of my question. But what can I do if there are things like rollups on GROUP BYs involved in my reports, and it therefore isn't exactly a "column" that needs localizing, but some portion of the output? ie the words "Total" and "Grand Total" in this example output: https://sourceforge.net/p/art/discussion/352129/thread/5ecb6a417e/d5bb/9997/attachment/ART.csv

Is it possible to get the current user culture as a parameter that can be passed into report sql (for internationalization purposes)? In considerations for design of reports able to run in multiple cultures, it would be nice to be able to internationalize our report column headers, but currently, as far as I can tell, there is no way to do this. One solution we have considered is that if we could pass the user culture into our SQL, we should be able to perform a lookup for the specified culture to...

Here is an example report output for "totals" and "grand total" via grouping sets, if it's any help.