<div dir="ltr">This past week I've uploaded a new patch <br><br><div><a href="https://gerrit.libreoffice.org/c/core/+/185810">https://gerrit.libreoffice.org/c/core/+/185810</a></div><div><br></div><div>The new patch handles formulas and allows the user to add database </div><div>information as input for a formulas. As mentioned last week, one </div><div>priority I had was to change the code paths for how a Report is saved </div><div>vs. how it is executed(i.e. shown to the user when clicking Execute Report</div><div>in the UI).</div><div><br></div><div>This has proved to be more complicated than anticipated. The main issue</div><div>is that up until now, I have been modifying the output filter for a </div><div>Report(xmlExport.cxx), with the goal of changing its output so that it matches</div><div>what the Pentaho Report Engine outputs. This breaks the functionality that saves </div><div>a Report, since this also uses the same output filter. The solution to this problem </div><div>is to have two output filters, one for executing a report and one for saving a report. </div><div>This will allow backwards compatibility for how Reports are currently saved and </div><div>loaded from file while also providing a separate path for executing Reports that </div><div>bypasses the Pentaho Report Engine.   </div><div><br></div><div>I have produced a document that explains how a Report is stored internally, </div><div>how it is exported as well as the two export paths that are currently used and </div><div>where the Pentaho call is located in the export path. It can be found here</div><div><a href="goog_712266676"><br></a></div><div><a href="https://nextcloud.documentfoundation.org/s/Ky3GkWz5TbDP93B">https://nextcloud.documentfoundation.org/s/Ky3GkWz5TbDP93B</a></div><div><br></div><div>I have also produced an odb document with a small example database along</div><div>with some saved Reports. WIth my patch pulled and built, the Pentaho call is </div><div>bypassed and when you open a saved Report, it is produced by the C++ code</div><div>in xmlExport. This demonstrates the progress the project has made to date. </div><div><br></div><div><a href="https://nextcloud.documentfoundation.org/s/3qZapNfoK9xFg5E">https://nextcloud.documentfoundation.org/s/3qZapNfoK9xFg5E</a><br></div><div><br></div><div>As far as next steps, I will be working on modifying the export path to distinguish </div><div>between the two scenarios, 1) to save a report and 2) execute a report. The </div><div>next step will be to create a subclass of the current xmlExport implementation. </div><div>The subclass will handle scenario 2) and will serve as the export filter that will </div><div>bypass the Pentaho Report Engine while the base class will handle saving a </div><div>report.</div><div><br></div><div>That's it for this week, thanks for reading and have a good week!</div><div><br></div><div>Adam Seskunas </div><div><br></div><div><br></div></div>