To recreate: - create a new report from SQL - enter "SELECT <<whatever|whatever>>" and try to save - Get an error "Errors found when processing parameters for report: whatever: The authorized value category (whatever) you selected does not exist." - Error provides two options, "Save Anyway" or "Edit SQL" - Click Edit SQL, get taken to an empty report "Edit SQL" wants to take you back to the previously saved version of your report. But if you've ended up at this error from a brand new report that's never been saved, then the "Edit SQL" button is going to take you to a blank report, trashing whatever you've just written. If we can't retain that SQL through the error on an unsaved report, then we should remove the Edit SQL button when working with a report that hasn't been saved yet.
Looks ok for me on master (the SELECT is in the SQL textarea), did you test on master?
I just tested this on master a bit. There's some inconsistency in behavior here, perhaps based on complexity of the report? My original example of "SELECT <<whatever|whatever>>" does not drop any content when you try to save it. If I try to save a report of: SELECT if(1=1,'dur','ohno') WHERE poodle=<<dog|woof>> I click save, get the parameter error message, click "save anyway," end up with: SELECT if(1=1, Or, for a less silly example, this report has "branch" where it should say "branches": SELECT itemtypes.description as itemtype, branchname, sum(if(type='issue',1,0)) as issues, sum(if(type='renew',1,0)) as renews FROM statistics LEFT JOIN itemtypes USING (itemtype) LEFT JOIN branches ON (statistics.branch=branches.branchcode) WHERE date(datetime) BETWEEN <<Start date|date>> AND <<End date|date>> AND branch like <<Branch|branch:all>> GROUP BY itemtype, branch And after trying to save it I end up with: SELECT itemtypes.description as itemtype, branchname, sum(if(type=
Altogether, I'd be happy see to see this check and error message moved to when a report is run, rather than when it's saved.