I have a report that makes use of the datasource field in the parameter definition. I try to reuse as much as possible so this exact same report can be run by users with different roles. When role A runs the report, the result of the datasource is a dropdown list containing many values. They pick one of these values and the report runs just fine. However, when role B runs the report, the result of the datasource will always be ONE value. When it displays in the dropdown list, it displays fine but the prompt also displays and is selected by default. So the user, even though there is one real value in the list, has to always select this value before hitting submit.

I wonder if it makes sense that if the result of a datasource returns 1 element and required is true, if the input control type is

  • select, no prompt is displayed
  • radios, the radio button is preselected
  • hidden, regardless of the required value, if a datasource is defined, the default value for a hidden field is [0] of the returned list

I guess I'm after more programmatic control over the initial state of the parameters without having to drop into php.

Comments

Pierre.Vriens’s picture

Pierre.Vriens CreditAttribution: Pierre.Vriens commented

Randy, I wonder if you could get it to work with a combination of these existing features (not using any PHP at all ...):

  1. specify a default value for the report parameter equal to that "result of the datasource will always be ONE value" (for role B), assuming that such value is always the same for such users (i.e. that this fixed value does not change over time, or depends on the actual user, etc).
  2. use the FrxParameterForm renderer (with a div containing frx:renderer="FrxParameterForm"), which allows for Customizing various aspects of the rendering of the report parameters input form. Here is an example of that (in this case for a report parm = role, which has a default value of "3"):
    <head>
  ...
  <frx:parameters>
    <frx:parm id="role" data_source="drupal/roles" type="select">3</frx:parm>
  </frx:parameters>
  ...
  </head>
  <body>
    ...
    <div frx:renderer="FrxParameterForm" frx:title="Report Execution Parameters" frx:collapsible="1" frx:collapsed="0" frx:submit="Show users and their permissions" id="parmeter-form">
    <p>Role Description: {role}</p>
    <p>Select a role and hit the button to run the report.</p>
    <p>{submit}</p>
    </div>
    ...
  </body>

    In your case such div should contain what's needed for role A users (the select list to pick from, etc).

  3. add an frx:if tag (conditional rendering) within that div containing frx:renderer (as in previous item 2), so that the report parameters input form is only shown for role A users (and hence role B users will execute the report using the default value for the report parm, since they even won't see a report parm form). By adding the frx:if="some_test" attribute to any HTML tag, that HTML tag is only rendered on condition that "some_test" evaluates to true. The normal php rules apply to values specified here: frx:if="0" evaluates to false, while frx:if="1" evaluates to true. Normally you would use Token Replacements in the attribute to map this to some column in the database (or value of a tag in case of data stores in XML format). Here is an example of that:
    <sometag frx:if="{my_column}">something surrounded by sometag</sometag>

    For this frx:if to work you'll need some appropriate token of course.

Note: I've never tried/experimented with using an frx:if and frx:renderer="FrxParameterForm" within the very same tag, though I cannot think of any reason why you cannot use them together (on the same tag). If my other assumptions above are correct for your case, I'd be curious to learn about your results.

reckhoff’s picture

reckhoff CreditAttribution: reckhoff commented

Unfortunately, the value can be different for users who are of role B. But I hadn't considered frx:if and frx:frxparameterform as an option and will brainstorm on that idea for a while to see if any other solutions present themselves. thanks for the tip!

metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented

Generally the required parameter means that the parameter must be specified. I hesitate to change the behavior of the parameters form to behave differently as in some cases we want make sure the user knows what option is being chosen (it might not be anywhere else in the report). I'd be willing to consider the hidden option you are talking about as the definition of a hidden field with a data source is not well defined. I think it will be pretty difficult to implement because normally the parameter form is built after the report is rendered so that we can tell whether data was returned by the report before decide whether to collapse fieldsets. There may be other ways to think about this, so I'll need to give it some thought... maybe something that was controlled via a skinfo setting or a report option... hmmm...

One approach that you might not have thought of is to make the data block used in the report not really Require the parameter, but have it default the value in certain cases. Sometimes I do this with --IF= statements or --CASE statements in the data block. I don't know if that fits your requirements (from what you said I don't really think it does).

Also know that if you uncheck the "required" box and there is a drop-down in true drupal fashion, it will pre-fill in the value. You can technically leave the parameter "not required" from the report perspective, but just have the report return no data if it is not specified. This would mean that the user would not have to select the dropdown from the list, but would be able to just hit submit after reviewing the parameters. This is kind of how Drupal deals with select boxes by default, so I have not tried to code around it for consistency's sake.