There does not appear to be anyway to open a report from a macro (e.g. button on a form) and apply a filter to that report. Similar to how you can open a form from a macro using a filter. Something like this should work:
oReport = ThisDatabaseDocument.ReportDocuments.getByName("MyReport")
oReport.filter="( ""tbProjects"".""ProjID"" = " & ProjectID & " )"
The only solutions I have been able to find require either generating a temporary table on the fly and opening a report against that. This solution only works in a single user environment.
The other solution is to open the report in design mode modify the filter then generated a report. This also is problematic in that user must have write access to the LO file, also an non-starter in multi-user environment.
Ideally we can open reports just like forms with externally applied filter.
You could write your filter-values in a separate little table. This values could be read with a query. Only SQL-function you need is IFNULL(...) - then the filter works, when there is an input in the filter-table, or the whole data were shown.
I changed the Status to "New", because I can confirm the behaviour you have described. Changed also the Platform to "All"
I think separate table is a possibility, would have to write out everything for the report then delete the records after the report is created. How would I make that work in a multi-user environment?
In a multi-user environment the input in the little filter-table must be blocked during the time the query needs it. Could be a way to create a view. The database knows, who long the view works. When the view is working the input in the filter-field could be blocked through the user.
I have not tested it - don't work with Base in a multi-user environment.
Have set the Importance to "enhancement", because the only way to connect with a macro to the report is to open the report - nothing else.
(In reply to comment #2)
> I think separate table is a possibility, would have to write out everything for
> the report then delete the records after the report is created. How would I
> make that work in a multi-user environment?
Most database systems have a notion of temporary table that are specific to one connection / session.
But that is still an ugly *work-around*, I'd prefer we fixed this bug.
The difficulty lies in the fact that a report opened in normal (non-design) mode is not a report anymore, but a writer document. So indeed, manipulating it as a report does not work.
How about just letting people edit reports in a read-only file, but just not let them save the file? That would solve this problem cleanly, and probably others.
Adding self to CC if not already on