It would be helpful if a datepicker widget could be tied to particular reports runtime parameters. It would be logical to integrate it with the current syntax for using authorized values. The authorized values syntax looks like this: <<Question to ask|authorised_value>> For date fields, you could do: <<Last seen|date>> ...and have the script check for the "date" parameter.
*** Bug 7640 has been marked as a duplicate of this bug. ***
Created attachment 8136 [details] [review] Bug 5698: Add date picker option to SQL Runtime Parameters Adds a date picker for SQL reports with the 'date' authorised_value. Updates help documentation for this new feature, as well. To test: 1. Create a new report with two date parameters, using the syntax: <<Label for this selection of date|date>> 2. Run the report 3. Select dates 4. The SQL generated should format the dates properly in ISO, and keep track of which date is which
Created attachment 8138 [details] [review] Bug 5698: Add date picker option to SQL Runtime Parameters Adds a date picker for SQL reports with the 'date' authorised_value. Updates help documentation for this new feature, as well. To test: 1. Create a new report with two date parameters, using the syntax: <<Label for this selection of date|date>> 2. Run the report 3. Select dates 4. The SQL generated should format the dates properly in ISO, and keep track of which date is which Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Created attachment 8220 [details] [review] Followup proposed for discussion QA Comment, Hi Ian, Your patch works as expected. But I am annoyed the html code is generated in the perl script (ok, it is the code style of this page...). What do you think about this patch ? It is not clean, but perhaps a bit better ? :-/ I can understand if you do not agree with it and in this case I will pass QA your patch. It is just a proposition ;)
I agree that generating the code in the Perl is less than optimal. That's how it works for all the other SQL params, so rather than rearchitect the whole section, I just carried through on the existing paradigm. But, that said, your solution is much more elegant, and does the same job. Marking as Signed off and Passed QA.
patch and follow-up pushed
I just did a pull on master, but don't see this feature. Nicole
(In reply to comment #7) > I just did a pull on master, but don't see this feature. Nicole, when I test/push, I do that locally, then push on public repo, after some push. I changed the status less than 2 hours ago, it's still not on public repo, pushed just on my local git ;-)
Okey Dokey!
Love it! Works Awesome!!