-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Hi,
I'm developing a module that uses file-fields in project-settings to handle files supplied to the module by project managers. I've found a bug in how the EM framework handles file uploaded to the configuration on a project.
The file fields are nested under repeatable sub-settings, so that each file is nested together with a set of additional configuration fields (see attached config.json example of a "file" field linked to a "file_desc" text-field).
The configuration could look like this, when 3 files have been added (and described):
BUG 1: If I now delete the 2nd file from the dialog, the EM framework ignores that the file is a part of a nested sub-setting, and just removes the file reference from the config, as if the file field was just repeatable alone and not linked to other config options. The result is, that the 3rd file takes the place of the 2nd in the configuration:
In the data base list of files changes from: ["347","348","349"] to ["347","349"] where the file_desc remains: ["feet.png","thumbs-up.png","tudse.png"]
BUG 2: If I instead of deleting a file deletes the entire 2nd sub-setting, the EM framework ignores the file list when deleting the other sub-setting values from the respective lists. This results is that the file list remains: ["347","348","349"] while the file_desc list becomes: ["feet.png","tudse.png"]. The result is that the 3rd configuration gets converted to configuration 2 (which is OK), but it is now associated with the file from the former 2nd configuration, and the correct file is left hanging in the list in the 3rd spot.
To me it looks like that the EM framework handles the files independent of the sub-setting group they are attached to. I.e. I would expect the same result, if the file field was repeatable outside of the repeatable sub-setting group of fields.