Multivalue Parameter Default

Yes, if you define a parameter in the report, you should be able to specify "default values" for the parmeter to be multi-value by separating each value by |.

Data and Lookup fields are used to populate the list of possible values, kind of like this:

<frx:parm id="race" label="Race/Ethnicity" data_source="test/filter/race" data_field="tid" label_field="name" type="multiselect">3|5|7</frx:field>

In here the block test/filter/race would be a block that returned tid and name for all possible race/ethnicities that a user COULD select, and the default selected values would be in specified in the report. Users could still override the choices.

Does that meet your needs?

No there is no real reason why it was set up that way. I think you've uncovered a bug in the parameters form. You are also correct that this doesn't appear to be well documented, which is something that I need to fix.

With regard to the programatic solution, hook_forena_parameters_alter was really invented to inject current fields into the parameters before report rendering and after form submission, so no worries there.

You can technically use your approach to deal with this using the form_alter hooks, and it seems like you got most of the way there. Here's the magic. When you get to the form the second time, you'll notice that the parameters are on the URL in $_GET, so you should be able to tell whether a user has pressed submit on the form based on whether those $_GET parameters are there. Make sense?

I have the same problem - if there is only one value in default parameter, then there is no selection in filter form, while report data is correct - parameter is passed.
Except in my case the solution with "3|" did not work as it passed empty string to my oracle db integer field:
pcb.c_status_status in ('1','4')
And therefore caused an sql error.
I am yet managing such cases by choosing two default parameters for forena reports list or if in menus, just by specifying them in URL.

One thing which I neglected to mention is that you can specify the types of input parameters in the data blocks in the info section of the block, like this:

select * from mytable where value in (:array_value)
--INFO
type[array_value]=array

Although if you are using the OCI driver there is a slight difference in that values of this type do not get the parens:

select * from mytable where value in :array_value
--INFO
type[array_value]=array

Please try these fixes and report back.

Result - negative.
I have v. 7.x-4.7

Tried:

my large sql
--IF=:st_e
		and
		pcb.c_status_status in (:st_e)
--END
my order by etc.

 --INFO
type[st_e]=array

In frx file default parameter value defined as:
...type="multiselect">1|</frx:parm>
This is workaraound to get showing selected parameter in the form.

And in any case getting:

and
pcb.c_status_status in ('1','')

That in my case causes error, because of c_status_status type is number.

If I use default parameter just single number, than query works well, but parameter form shows no value selected, that is not true and is misleading for a user.

Previous case was on PostgreSQL, there I always use " IN (:my_parameter) " in SQL template / data block.
In another case with Oracle, where I have to use " IN :my_parameter ", because it depending on number of parameter values use or not use brackets the comment at the of SQL template / data block helps and I gettings brackets around parameter even if it is single value parameter.

I have another question to this subject:
What would be the good approach to implement calculated default parameter.
F.ex. for date based parameters - to set current month or last month?

Take away the default parameter of 1| and try again and see if it doesn't work for you. I'll do additional testing on postgres when I can to make sure it works properly. The idea behind type[ste]=array is that it should cast parameters as arrays.

We're getting off topic and maybe we should open a separate issue to discuss this, but there is no current way of doing arbitrary calculations as default parameters, but forena does support type[parm]=date which will try and convert dates to PHP dates using php date/time functions. That lets you specify default dates in formats like "3 days" or "3 days ago" or "2 years ago" basically any of the relative time formats. There is also support for xpath evaluation expressions for numeric calculations in a report which can be passed down to data blocks using frx:parameters attributes any place that frx:block is being used.

I forgot to mention the difference between the in (:ste_e) and in :ste_e is due to driver differences in the database. In Oracle I have native array data types that aren't really available and I wanted to support the full array of set syntaxes such as "member of" and other oracle native constructs.

Take away the default parameter of 1| and try again and see if it doesn't work for you.

If I use default parameter just single number, than query works well, but parameter form shows no value selected, that is not true and is misleading for a user.

Sorry.... obviously need more coffee. I'll check this out and work on a patch.

I haven't had time to test it yet, but this patch seems like it should solve the problem. Would you be willing to test it?

Tested with my PHP 5.4 in Apache2 on Winserv2003
Worked in Forena with PostgreSQL 9.5 and Oracle 11

For default parameter calculations - are there any examples/links or should I create new tread?

Thank you for the tests, janeks. There isn't a specific example targeted at what your talking about, but there are some references in the documentation:

http://forenasolutions.org/reports/help.data#sqlparameters - See date data type
http://forenasolutions.org/reports/help.reportingfrx#fields - See calc attribute
http://forenasolutions.org/reports/help.reportingfrx#anatomy - See frx:parameters attributes

If these don't help you put it together, lets open a separate issue.