One nice feature would be to have statistics page that allows you to dynamically generate any type of statistics on the various modules.  Some examples: Total rows per module (already in database section) Adds/Updates per day Top used categories It should be flexible to allow any type of statistics to be pulled using the aggregation fields. It's probably handy to be able to store presets so they can be easily rerun later (prolly wise to store them in the "JAS" project so the...

Float and price fields should have round/floor/ceil field mutilations Mutilate::round(number, precision=0, mode=false) mode: normal, floor, ceil  if precision > 0 and mode = floor/ceil:  floor(number * pow(10, precision))/ pow(10, precision) Data::addMutilationFormat_Template

High priority and low impact can and should be quickly fixed whereas low priority and high impact will end up lower on the list. With this in mind a "ranking" can be determined using the priority and impact fields (similar to the risk score in the Procon plugin). Priority scores:  High Medium Low Impact score: LowMedium High Ranking = Priority score + Impact score - 1 Examples: 1 = High priority + Low impact 2 =  High priority + Medium impact 2 = ...

Generally show_from+show_total are used to split data over multiple pages. As such it's seems logical to support this natively. If show_page is set it should be used to calculate show_from (show_page * show_total) prior to getting the data (and thus overwriting the set show_from). When the data is gathered and show_count is set this value should be used to calculate show_pages ( ceil ( show_count / show_total)).

Currently the page browser logic in the lister plugin only remembers the sorting and the filters in rewrite mode. It should use a more generic approach where it reads the relevant filters from the Data object and use that. Additionally it's probably a good idea to split off the page browser logic in the lister plugin from the output function so other plugins can easily reuse this logic.  Convert by: JAS13OCT014

The file (and image) field should get an additional field for the MD5 hash. The /files/ would then need a "MD5" variable that would download a "text/plain" file with the hash as content. The filename can be generated based on the original filename and a .md5 suffix (filename.ext.md5).  Note that it's probably wise to add a MD5 property to the file/image fields to allow it to be enabled/disabled.