In an effort to help users properly configure report events (printer/email) we will be tightening up the validation for creating these bindings so that any report that a user wishes to be associated with an email or print event must have at least one required parameter. We have run into some problems where users are binding reports without any required parameters resulting in massive, unfiltered reports being printed or attached to outbound emails. That does not mean that a report can’t be custom developed to take in a required parameter and not use it, but this should only be done to achieve a specific outcome like attaching a static document to an outbound email or printing a company logo label for use on a box. These uses cases have a finite report length (single page, etc.) and will not cause any load problems like reports that generate massive amounts of labels, pages, or tables might.
In addition to this protection mechanism we are also introducing a rate limit between reports being generated and the fetching of assets (barcodes, images, etc.) by those reports. This will prevent massive reports from flooding requests for resources into servers when most likely the report was run in error or mis-configured when run. We have allocated a sufficient amount of throughput such that normal day to day use will not be impacted, but asset heavy reports will noticed a slow down in rendering speed to better balance access to servers by all users.