Hello,
As announced in the following article https://support.safe.com/hc/en-us/articles/44279253166605-Nested-User-Parameter-Deprecation, Safe have deprecated nested user parameter starting with versions patching the recent security issue.
First of all, the deprecation really took us by surprise, simply because it was written nowhere in the security advisory article the potential regression of applying the patch. We only noticed the new deprecation by checking the quaterly FME Knowledge. In my opinion, Safe should have better communication on new major deprecations like this one (as a matter of fact, our official FME Partner haven’t heard of this deprecation before us asking them).
Moreover, I understand that due to the criticality of the issue, Safe had to patch it in a hurry, but FME Flow behaviour is less than ideal:
- Nested parameters being functionnal on FME Form but not Flow creates a major undocumented discrepancy between the two;
- Added to the fact that the error message is simply “There was an error submitting the job” in the interface, and having to check System logs to get the error is poor user experience. Also a normal author might not even have access to the system logs;
- The proposed workaround, while working, really kills the meaning of “parameter” and mix it with “attributes”. For example, a private nested parameter building an output path from (output_directory, output_filename) has no place in my opinion in the attributes of a feature (except for fanout, which in this case would be a valid reason!). I hope Safe can propose a better solution to that (I was thinking of making parameters mutable via a new transformer, but it may be difficult to implement technically)
I have not tested the patch myself, but does this deprecation include FME Flow parameters like FME_SHAREDRESOURCE_DATA which we heavily use?
Kind regards.
