QgsProcessingParameterFile extension option

[aproposinfosystems]

What is the bug or the crash?

When setting an input file with the QgsProcessingParameterFile in a plugin, for Linux if the selected file is a binary file it will not have an extension. When the plugin is executed in QGIS 3.20 on Debian 11.1, this will generate a "Wrong or missing parameter value: " error. If the executable file name altered to add an extension, such as .bin, it runs fine. This error does not occur on Debian 10.11 with QGIS 3.18 or in earlier versions of QGIS this problem does not occur.

I discovered this in using the QMarxan plugin I created, however I believe the error to be some undocumented change between 3.18 and 3.20 in the QGIS Python API.

Steps to reproduce the issue

See above

Versions

3.20

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

I see two possible options to resolve this problem:

1. If it is possible to set the file extension or filefilter parameter to accept files without extensions, then this needs to be documented in a clear way.
2. The default behaviour should be as was found in the 3.18 and earlier versions where files without extensions were accepted.

Note: I did not try a new QGIS profile as it is not relevant in this case.

[alexbruy]

In latest QGIS versions if no extension is set, a default file filter will be used. So all you need is to define correct fileFilter string for your parameter. It is documented in the API docs.

[alexbruy]

Please calm down and re-read previous comment as well as API docs. There are two ways to configure file parameter now: one is by specifying extension and another one is by specifying file filter string. The latter allows to set up any file filter(s) and maintain the same behaviour as before when files without extension does not trigger "MIssing parameter value" error. it is just a matter of correct setup.

[alexbruy]

Right, because '*' is not a correct file filter string. Correct file filter does not generate any errors and allows files without extensions.
I would not close this without checking it and ensuring that everything works as expected.

[aproposinfosystems]

I summarize here findings for others in case they encounter this same problem. The function does in fact work as asserted, however in my numerous searches of the API docs I was unable to find any details on the correct format of the fileFilter parameter. The naive use of a * appears at first to work by allowing selection of files without extensions in the GUI, however the error described above is raised before processAlgorithm method is executed. If however the fileFilter glob values are provided within parentheses, (*), both the GUI and the passing of the parameters works. This inconsistency creates the appearance of a bug when combined with lack of clear details in the API docs.

[nyalldawson]

@tsw-apropos would you mind submitting a PR with appropriate revisions to the documentation? Experiences like yours are very valuable to other API users, so it'd be a shame not to use this opportunity to improve the docs!

[aproposinfosystems]

@tsw-apropos would you mind submitting a PR with appropriate revisions to the documentation? Experiences like yours are very valuable to other API users, so it'd be a shame not to use this opportunity to improve the docs!

Yes I will do so in the next few weeks as I have time. Good suggestion.