Scenario: Confusion between parameter name and function name

[ikedas]

Version

6.2.38 and earlier.

Installation method

Any.

Expected behavior

By implicit inclusion feature of scenario file, "include.<action>.header is automatically added to evaluated scenarios".

Actual behavior

If a scenario corresponds to a compound list parameter, that parameter name is used as <action> above, instead of scenario function name.

Example:

Scenario file d_read.xxx corresponds to list parameter shared_doc.d_read. It tries to include header file include.shared_doc.d_read.header instead of include.d_read.header.

Additional information

• PR to fix this bug will be submitted soon.
• This bug has been included in very earlier version of Sympa, and it is probable that several sites use incorrect file names to enable inclusion. Correction should be announced at the time of new release.

[ikedas]

I withdrew the PR I have submitted. Because I found that several other confusions between function name and parameter name are found in current code.

I'm planning refactoring (rearranging) code related to scenario feature. These bug will be solved with that work (in early this year).

[dverdin]

The general rule being that the scenario name matches the parameter name, we should stick to this and rename scenarios when a parameter is renamed. For example, when d_read became shared_doc.d_read.
In that case, the scenario code is not faulty. It does exactly what it is supposed to do.

[ikedas]

@dverdin, that rule is no longer enforced. See for example archive.web_access parameter vs. archive_web_access function, while tracking.tracking vs. tracking. From the beginning, topic_visibility function does not have corresponding list/domain parameter.

Another example of confusions between function and parameter is dump_scenario page of wwsympa. This doesn't work with scenarios for shared documents.

[dverdin]

So how to do? shall we keep a table of pairs such as (parameter => scenario_name)? That would easily solve this problem.

[ikedas]

I'll submit a PR later (in this month or next). Basically, it may solely use function name to specify scenario function with new(), request_auth() etc., and gives a table mapping function names to list/domain parameters.

[ikedas]

PR above may fix this issue. I'd like to merge it in this week.