Bug 208477 - Allow cascading parameters to allow multiple selections
Summary: Allow cascading parameters to allow multiple selections
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.3.0   Edit
Hardware: PC Windows XP
: P3 enhancement with 15 votes (vote)
Target Milestone: Future   Edit
Assignee: Zhiqiang Qian CLA
QA Contact: Liwen Chen CLA
URL:
Whiteboard:
Keywords: plan
: 218588 231345 298488 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-01 16:35 EDT by Tavish Fraser CLA
Modified: 2017-05-30 10:15 EDT (History)
19 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tavish Fraser CLA 2007-11-01 16:35:56 EDT
Cascading parameters currently only allow selection of one item per list.  It would be very useful to be able to allow multiple selections per list.

The simplest case is when multiple selection is only allowed for the final parameter in the cascading group.  In this case we allow the user to select multiple options on this last list and use these in our report (e.g. in an "in" clause of a sql query).

A more complex case is when multiple selection is allowed on other parameters in the group.  In this case, when a user selects multiple values for a parameter, the values for the next parameter list in the cascading group would need to include the values relevant to all selections, presumably removing duplicates.

The groundwork has been laid for this in the engine by bug id 206464.  The other things needed to do would be to allow cascading parameters to be flagged as allowing multiple values in the designer, handling these in the viewer, and ensuring multiple values are dealt with properly for these when submitted to the engine.
Comment 1 Lars Johansson CLA 2008-04-03 03:10:19 EDT
(In reply to comment #0)
> Cascading parameters currently only allow selection of one item per list.  It
> would be very useful to be able to allow multiple selections per list.
> The simplest case is when multiple selection is only allowed for the final
> parameter in the cascading group.  In this case we allow the user to select
> multiple options on this last list and use these in our report (e.g. in an "in"
> clause of a sql query).
> A more complex case is when multiple selection is allowed on other parameters
> in the group.  In this case, when a user selects multiple values for a
> parameter, the values for the next parameter list in the cascading group would
> need to include the values relevant to all selections, presumably removing
> duplicates.
> The groundwork has been laid for this in the engine by bug id 206464.  The
> other things needed to do would be to allow cascading parameters to be flagged
> as allowing multiple values in the designer, handling these in the viewer, and
> ensuring multiple values are dealt with properly for these when submitted to
> the engine.

Any news about the activity for the request for enhancement?

One thing we've come across in BIRT is that it seems that multiple selection of parameter values is not allowed with cascading parameters. There seems to be some desire for that in the community, with one request for enhancement entered into Bugzilla, 208477, Allow cascading parameters to allow multiple  selections, https://bugs.eclipse.org/bugs/show_bug.cgi?id=208477. It seems to be scheduled for BIRT 2.3.0.

Will support for multiple selection of cascading parameters be included in BIRT 2.3? While waiting for 2.3, is there a workaround for this problem?

We also tried using multiple selection of parameters (not cascading) but didn't succeed. Clicking on the data set we saw the error text in italic below.
The report parameter {0} allows multiple values, which can not be used to link with data set parameter. However, we read http://www.birt-exchange.com/modules/wfdownloads/singlefile.php?cid=2&lid=233. The key thing in taking care of the multiple parameters here seems to be having a filter in the output dataset. However, this is not an optimal solution since the filtering is done after the query. Down below is a little bit on how this can be solved in SQL Server reporting. Would it be possible to do this filtering before calling the data set and subsequent filling with data?

We're using Eclipse BIRT all-in-one 2.3M5 and java 1.6u3.

Initial work for us has gotten BIRT to work with stored procedures together with input parameters. Works fine. Now we want to go further and convert some  of our old reports to BIRT. In those old reports we use multiple selections in cascading parameters. In the reports, we convert multiple parameter  selections to a comma-separated string before calling associated stored procedures. We've done exten

Below how the work goes:
----------

For a call to stored procedures:

  - a number of input parameters
  - input parameter usually a string
       (which consists of comma-separated values)

  CREATE PROCEDURE  [owner].[stored_procedure_name] @param1 as VARCHAR(max), @param2 AS VARCHAR(max), ..., @param_n as VARCHAR(max) = NULL  

  DECLARE @sql			NVARCHAR(max);

  SET @sql = 'SELECT 
	     ...
	     ';

  EXEC sp_executesql @sql,...


  when @sql gets its value, the comma-separated input values get splitted into proper values for the sql statement.
  e.g.
   
     SET @sql = '....'                                                           + 
                ' AND table.column IN (' + split param1 into proper values + ')' + ...

----------
In SQL Server reporting, before calling the stored procedures, the input values to the stored procedures (comma-separated strings) are constructed using  the Join command which splits the values into comma-separated values.

Would it be possible to provide ability for multiple selections in cascading parameters in BIRT together with something similar to the Join command? Then  the rest might be up to the users responsibility?

Lars Johansson

Comment 2 Vincent Petry CLA 2008-05-18 22:40:50 EDT
*** Bug 231345 has been marked as a duplicate of this bug. ***
Comment 3 Colin Sutton CLA 2009-04-18 19:33:10 EDT
Would it be possible to add a new option to the set-up of a simple parameter's dynamic dataset "re-evaluate this parameter's dataset when any other parameter changes" (default 'no' for compatibility).
This would solve the problem both for cascaded parameters and simple parameters based on datasets with interdependencies.
There would have to be a check for cyclic dependency, preferably at the time of definition.
Comment 4 Zhiqiang Qian CLA 2009-06-01 04:23:26 EDT
Need more investigations.
Comment 5 Zhiqiang Qian CLA 2009-07-15 01:23:01 EDT
Move to future for more investigation.
Comment 6 Rima Kanguri CLA 2009-07-23 18:34:31 EDT
*** Bug 218588 has been marked as a duplicate of this bug. ***
Comment 7 Simo Neuvonen CLA 2009-08-11 04:37:04 EDT
As shown in 
http://www.scribd.com/doc/15350321/BIRT-Multi-Value-Cascading-Parameters
is is possible to select multiple values from a cascading parameter listbox.

However, that seems work only when using the automatically generated parameter page. Would it be hard to add support for using a custom parameter page (via JSP tag library) ?
Comment 8 Zhiqiang Qian CLA 2010-05-06 02:52:57 EDT
We support multiple values for last child in cascading parameter group now. Need investigation whether to support the complex case.
Comment 9 Zhiqiang Qian CLA 2010-05-18 06:45:17 EDT
*** Bug 298488 has been marked as a duplicate of this bug. ***
Comment 10 Emanuel CLA 2011-09-23 08:30:53 EDT
Hello, anyone news about the complex multiple? so values also for parents lists?
Comment 11 Piero Faieta CLA 2017-05-30 10:15:00 EDT
Hello, any news on this issue. The solution described on http://www.scribd.com/doc/15350321/BIRT-Multi-Value-Cascading-Parameters with Birt 4.6 doesn't work anymore. Thanks