Currently JAS uses the Data field values to build up the WHERE clause in the SQL query (and Storage::_filterDataset) in a straightforward but limited way. It should be possible to get data via a more flexible method that allows for advanced nesting.  Example: SELECT *  FROM blog_entries    LEFT JOIN blog_tagsmapping ON  blog_entries.nr= blog_tagsmapping.blog_entries  --automagically determined based on where clause   LEFT JOIN blog_tag...

JAS should support PostgreSQL (and optionally other databases). The post sensible way seems to be to have a base SQL class which contains the majority of the query components (SELECT, INSERT, UPDATE, DELETE, FROM, WHERE, ORDER BY, etc) which can be overridden by the extending classes.  An interesting option would be to use PDO for the base class as this will support more than just MySQL and PostgreSQL. Additionally it allows for "named variables" for prepared statements which should m...

Currently when setting the 1:* reference field value the MySQL use referenced field instead of the ID field of the referenced module. Using the former is rather useless since that's effectively the ID field of the original module. So change: FROM `module` LEFT JOIN `referenceModule` ON `module`.`nr`=`referenceModule`.`referenceField` WHERE referenceModule `.`referenceField `="123" To:  FROM `module` LEFT JOIN `referenceModule` ON `module`.`nr`=`referenceModule`.`referenceFi...

JAS should support JSON parsing and rendering which in turn can be used for a full-fledged read/write API. The JavaScript HTTP class should be extended to support this as well. 

It should filter out non images

Currently the MIME database (include/mime.xml) is a static list provided as part of JAS. It would be handy if this list could easily be updated via the backend.  The question that comes to mind however is whether upgrade should overwrite a customized version. It seems rather annoying if you spend time to add your own MIME types that are subsequently forgotten when JAS is upgraded. Maybe adding a flag "custom" to the XML file to indicate it shouldn't be touched by upgrades.

The JAS backend should have a filter section to more effectively drill down in the data. the filters should be automatically generated based on the module (similar to the CMS). Text fields should have a inline dropdown with available values (like the search box). Additionally it should remember the last set filters if the user comes back to the page later. This will require a "Reset" button to set all values to their defaults.

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 = ...