CDR Tickets
| Issue Number | 3986 |
|---|---|
| Summary | Board Meeting Dates Report - "By Date" Option Not Working |
| Created | 2015-09-30 12:31:49 |
| Issue Type | Bug |
| Submitted By | Juthe, Robin (NIH/NCI) [E] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2015-11-12 12:22:16 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.171119 |
Selecting the "Display by date" option for the Board meeting dates report is giving us an error message:
Invalid parameter value received: "ByDate"
This issue appears to be unresolved, even though it was in the Feline sprint. Should it really be in Darwin?
Fixed on DEV.
Moved fix from DEV to QA. The fix on DEV is going to disappear until the Feline patch makes it to production and the fix is merged into trunk (and from there into Darwin).
This has been backed out of the svn Feline branch and checked into the Darwin branch (to reflect the migration of the ticket from one release to the other).
Fix has been removed from QA (which has the Feline changes but not the Darwin branch).
Verified on DEV.
This is looking good, but the "By Date" option has light and dark gray backgrounds in the table of results. Is this report controlled by cdrcgi.Page and cdrcgi.Report classes? I'm guessing it's not...
~BKline, do you know if this report is handled by the classes mentioned above? Just trying to see if we can verify this and OCECDR-4037 (the issue to remove gray shading). Thanks.
This is going to be a longer answer than you were expecting, I think, but I hope it will be useful beyond the immediate context. This report was written back in 2008, and there have been only two changes (both made this past fall) since the newer report classes were developed. The first was to fix erratic grouping of rows by month (OCECDR-3952). I was able to fix this bug by removing four spaces. The other was to fix the parameter validation, which was preventing the report from running. I was able to fix this bug (OCECDR-3986) by replacing a single 6-character string with another 6-character string.
You may recall that the CDR development team offered (back when the project had more control over its workload and development resources) to modify the existing reports so that they reflected a consistent (and easy to modify globally) style, using an approach similar to what we're using for newly implemented reports, but this idea wasn't able to compete with other priorities. So what we've been doing for the existing reports is to make a judgment call each time we have to modify an existing report for some other reason, whether the requested modification would be extensive enough that implementing the modification using the new report classes would not significantly increase the level of effort. In the case of this report, both of the changes involved changing or deleting only a few characters in the context of a 17,000-line script, so the decision not to rewrite the script using the new classes/style was obvious.
Here are a couple of tips for how to recognize whether a report uses the new classes/style. The report request forms for the newly written reports (and those re-written to use the new classes) all have field sets which have maroon borders and captions, like this:
This report, on the other hand, has a request form that looks like this:
Another (geekier) clue can be found by right-clicking on the request form and selecting "View Source." The heading for the newer pages looks like this:
<!DOCTYPE html>
<html>
<head>
...
<link href="/stylesheets/cdr.css?v=201603211524" rel="stylesheet">...The source HTML for the board meeting dates report on the other hand looks like this:
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'
'http://www.w3.org/TR/html4/loose.dtd'>
<HTML>
<HEAD>
<TITLE>CDR Administration</TITLE>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'>
<link rel='shortcut icon' href='/favicon.ico'>
<LINK TYPE='text/css' REL='STYLESHEET' HREF='/stylesheets/dataform.css'>
<style type='text/css'>
body { background-color: #DFDFDF; }
*.banner { background-color: silver;
background-image: url(/images/nav1.jpg); }
*.DTDerror { color: red;
font-weight: bold; }
*.DTDwarning { color: green; }
TD.ttext { color: black; }
TD.tlabel { font-weight: bold;
text-align: right;
white-space: nowrap;
vertical-align: top; }
TH.theader { font-weight: bold;
font-size: small;
text-align: left;
white-space: nowrap;
vertical-align: top; }
</style>
<link type='text/css' rel='stylesheet' href='/stylesheets/CdrCalendar.css'>
<script type='text/javascript' language='JavaScript'
src='/js/CdrCalendar.js'></script>
<style type='text/css'>
body { background-color: #DFDFDF;
font-family: sans-serif;
font-size: 12pt; }
legend { font-weight: bold;
color: teal;
font-family: sans-serif; }
fieldset { width: 500px;
margin-left: auto;
margin-right: auto;
display: block; }
.CdrDateField { width: 100px; }
</style>....... with lots of custom style (CSS) rules embedded in the page.
I hope at least some of this is helpful information, rather than confusing blather. :-)
This is very helpful. I had been trying to figure out which ones were old vs. new based on the appearance of the report interface - font, organization, etc - but I hadn't noticed the consistent maroon border. Good to know there's also a way to check by viewing the source. Thank you!
Verified on QA.
Verified on PROD.
| File Name | Posted | User |
|---|---|---|
| newer-report.jpg | 2016-04-01 14:33:18 | Kline, Bob (NIH/NCI) [C] |
| older-report.jpg | 2016-04-01 14:33:18 | Kline, Bob (NIH/NCI) [C] |
Elapsed: 0:00:00.001685