id	summary	reporter	owner	description	type	status	priority	component	severity	resolution	keywords	cc	release
1737	Refactor how custom reports are stored/queried into a separate class	coling	bobbysmith007	Hi,\r\n\r\nAs you know from private email I've been working on a refactor to make it simple to incorporate reports for T&E into other plugins (e.g. my ClientsPlugin).\r\n\r\nWell I have now done this and I attach the results :)\r\n\r\nHere are the diffstats\r\n{{{\r\n setup.py                                       |   11 -\r\n timingandestimationplugin/api.py               |  220 ++++++++-----------------\r\n timingandestimationplugin/dbhelper.py          |   38 ----\r\n timingandestimationplugin/migrate/upgrade4.py  |   10 -\r\n timingandestimationplugin/reportmanager.py     |  142 ++++++++++++++++\r\n timingandestimationplugin/reports.py           |    9 +\r\n timingandestimationplugin/templates/billing.cs |    4 \r\n timingandestimationplugin/usermanual.py        |   17 +\r\n timingandestimationplugin/webui.py             |   43 +---\r\n 9 files changed, 258 insertions(+), 236 deletions(-)\r\n}}}\r\n\r\nI'll walk through the major changes:\r\n * Introduced a new reportmanager.py file/class\r\n   * This file is designed to be stand alone and independent (e.g. freely copyable to other plugins etc. It maintains it's own db schema version and will raise an exception if two plugins use different version on a given install. It provides methods to add/update reports and retrieve listings of reports etc. It has a concept of {{{maingroup}}} and {{{subgroup}}} for reports. This allows me to use the plugin name ('Timing and Estimation Plugin') as the {{{maingroup}}} and the two categories of report for the {{{subgroup}}}. These {{{subgroups}}} are purely cosmetic.\r\n * I introduced the concept of each custom report having a uuid. \r\n   * Although not strictly speaking necessary in this plugin, some plugins may require to reference specific reports and a uuid gives a way for them to do this in code. I generated uuids for each of your reports.\r\n * I significantly simplified the code in {{{api.py}}}\r\n   * This was possible due to the fact that the report stuff was refactored. The various tests for upgrades required were also significantly simplified as this is now based purely on a version stored in the {{{system}}} table. This was used somewhat before, but not overly wholistically, so this refactor changes that. This in turn has resulted in the removal of some methods from {{{dbhelper.py}}} that are now no longer called.\r\n * Simplified DB Schema tracking.\r\n   * As the {{{reportmanager.py}}} introduced a simple DB schema version tracking, I converted your current {{{migrate/upgrade?.py}}} system to use a similar model. This is a much simpler implementation of schema tracking and keeps the schema representation in one place which can aid visualisation. I appreciate you may not like this but as {{{reportmanager.py}}} has to be self contained I figured using a similar implementation here would be advantageous.\r\n * Efficiency Improvements\r\n   * As reports are accessed 100% from the database at runtime, I only import the {{{reports.py}}} file dynamically at the relevant part of the upgrade. This should save some resources on every page hit as api.py has to be parsed. If the version numbers are migraged from {{{usermanual.py}}} to {{{api.py}}} another efficiency saving could also be had, but this is beyond the scope of my patch.\r\n * Template Update\r\n   * I updated the {{{billing.cs}}} template appropriately and changed slightly how the data was passed to this template as a result of refactoring the code to the {{{reportmanager.py}}} class.\r\n\r\nI think that's about it, but if you have any questions please just shout and I'll do my best.\r\n\r\nHopefully this is acceptable to you and I've not wasted my time! \r\n\r\nThe patch applies cleanly on the trac0.10 branch but a few hunks fail on the trac0.11 branch. It should be easy enough to make it work and it may infact work if the changes on 0.10 branch are merged to the 0.11 branch first (not sure if the 0.11 branch has been synced from the 0.10 one for a while).\r\n\r\nI tested this on a clean install and on an upgrade. Both worked fine.\r\n\r\nI have not tested the SQL on postgres or mysql but I can't see any reason as to why it would not work as the SQL is all fairly simplistic.\r\n\r\nLet me know if you have any comments.\r\n\r\nCheers\r\n\r\nCol\r\n	enhancement	closed	normal	TimingAndEstimationPlugin	normal	fixed			0.10