CDR Tickets

The requirements document is attached. Thanks!

Adding ~duganal as a watcher.

Please provide the business case for the custom code which would be required in order to give the user the option to switch between checkboxes and a dropdown list at runtime for the Drug Types field on the report request form, ~oseipokuw.

As I mentioned in the requirements document either of the two options should be fine.

           (Either a list of all drug types with checkboxes or a drop-down menu of all drug types. Having both options would be great. If not, having a list of the drug types as a drop-down menu should be good. We also want the ability to select one or more drug types to run the report )

When we talked about this, the preference was for a list of drug types with checkboxes. However, knowing that the list could grow over time to fill a substantial part of the interface, we also suggested having a drop down menu as well, if possible.

At this point, having a list of checkboxes should meet our needs for the data we currently have.

1. Do you want the set of checkboxes to reflect the values actually used in the documents? Or do you want the report to parse the schema to get the list of all possible drug types? (I assume you don't want the software to use a hard-coded list of values.)

2. For DIS documents with more than one instance of the DrugType field, do you want a separate row in the report for each instance? If not, how should the multiple values be presented? And shouldn't the column header by "Drug Types" if we're not going to show a separate row for each drug type?

3. Since the requirements don't say, I'm going to sort the drugs by drug title.

1. Do you want the set of checkboxes to reflect the values actually used in the documents? Or do you want the report to parse the schema to get the list of all possible drug types? (I assume you don't want the software to use a hard-coded list of values.)

The second option is preferred with a list of all possible drug types in the schema.

2. For DIS documents with more than one instance of the DrugType field, do you want a separate row in the report for each instance? If not, how should the multiple values be presented? And shouldn't the column header by "Drug Types" if we're not going to show a separate row for each drug type?

Yes, a separate row for each instance is preferred. "Drug Types" header is also fine.

3. Since the requirements don't say, I'm going to sort the drugs by drug title.

The sort order is fine as well. Thanks!

Implemented on CDR DEV.

Just so tracking the requests can come up with more accurate numbers for the types of requests, I would suggest that a request for a brand new report would be a "New Feature" and a modification of an existing report (for example, OCECDR-4967) would be an "Improvement" (the existing tickets have the types backwards). Not something that necessarily has to be corrected for the existing tickets, just something to bear in mind for future requests. 😉

Could you place the report on the DIS menu. It is looks like it is missing from under "Other Reports".

Added to menu on DEV.

Thanks!

Please make "All" the default selection for the Drug Types.  I am able to select "All", and at the same time select other drug types. Could you modify it so that when I select other drug types, I won't be able to select "All" at the same time? It could get confusing with those selections.   Also, please make "Web Page" the default selection for the display option.

William will check to ensure that the report uses "All" as the controlling value for drug types if that selection is made in addition to other specific drug types.

I was able to confirm that "All" works as expected. Also, the default display option is the Web Page.

The Resolution of this ticket is "Won't Fix" - is that a mistake?

I have corrected it. Must have been my error when moving the ticket to DEV Verified. Thanks!

Ok thanks! Sorry to be nitpicky - just trying to see which ones will need QA testing and which ones won't 🙂. I'm planning to loop Christina in to take a look at this one.

Verified on QA. Thanks!

Verified on PROD. Thanks!