feature: adding possibility to remove file

[soleksy-splunk]

passing temp name during edit
for files that were already submited before

name passed only for edit action for rest is null
BaseFormView > Control Wrapper > FileInputComponent

[soleksy-splunk]

How it looks right now:
File name is not returned from backend so I just put "Previous File" just to put anything there

Edit page

w:

Clone page:

file possibilities:

1. file is encrypted and required:

• we got only the possibility to remove the current one and add a new one, it might be confusing as when encrypted the File name is displayed but value i empty so at update push we see this error
  value is empty just temp file name

2. file is not encrypted but not required

• we got all possibilities, value is used correctly (after edit/clone, value is correct) also got the possibility to delete complitely the file

3. file is not encrypted but required
   used same as 2, just after deletion we must push another file

4. file is encrypted and but not required:
   - previouse value of file is set as empty but we push File name "Previous File", which might be misleading, if user just updates other files and pushes changes without pushing new File it will be pushed incorrectly as encoded code

@artemrys as you raised ticket please have a look at those problems:

1. in 1st point it might be confusing but user can't break data
2. in 4rd point user might be able to brake data, currently the situation is the same but maybe it will be good to highlight it somehow?

[artemrys]

File name is not returned from backend so I just put "Previous File" just to put anything there

You are right, there is no concept of a "file" in the backend. We just save the content of the file if we can read it.

in 1st point it might be confusing but user can't break data

If "file" field is encrypted and required then we must ask user to upload a file every time they want to make a change to that entity. It is not convenient, I do agree, but I do not see how we can make it better.

in 4rd point user might be able to brake data, currently the situation is the same but maybe it will be good to highlight it somehow?

If a user previously uploaded a file and then wants to empty that value then we are sending empty string as a content? But the backend is still going to attempt to encrypt it. Which results in saving some encrypted empty string which add-on developer need to process themselves.

[soleksy-splunk]

@artemrys
in 4rd point the problem appears when user does not update file at all, those are the points that couse problem:

1. due to encrypted file data the base value is empty string,
2. user sees there "Previous File" as file name, so someone might suspecting that this file is correct etc.
3. due to file is not required there is a possibility to push that empty value

so to sum up the confusion might be that user thinks he is still using the old file but due to it is encrypted the value there is empty string

idea: maybe when we got both of them provided we can just display a simple label "File is empty"/"Value of the file is empty" or sth like that.

currently that issue is still there, so thats not something we are creating, but maybe we can improve it somehow

[artemrys]

@artemrys in 4rd point the problem appears when user does not update file at all, those are the points that couse problem:

1. due to encrypted file data the base value is empty string,
2. user sees there "Previous File" as file name, so someone might suspecting that this file is correct etc.
3. due to file is not required there is a possibility to push that empty value

so to sum up the confusion might be that user thinks he is still using the old file but due to it is encrypted the value there is empty string

idea: maybe when we got both of them provided we can just display a simple label "File is empty"/"Value of the file is empty" or sth like that.

currently that issue is still there, so thats not something we are creating, but maybe we can improve it somehow

Do you think we can solve this issue by simply not allowing a file type to be encrypted and not required?

[soleksy-splunk]

Do you think we can solve this issue by simply not allowing a file type to be encrypted and not required?

@artemrys
yea that should solve the problem, but when i think generally about files I can imagine a scenario when file is optional but also i would like it to be encrypted, not standard scenario but might happen.

Other possibility i see is journey were only if file is encrypted and optional plus user tries to push that old encrypted file without any change, some warning pops up "You can't use previous file", so you basically need to delete it manually if you do not want that change to happen at all, then the user is aware that empty file will be pushed or at least it is more intuitive.

Something else might be that for this case we can just remove that filename, so it looks more like there is not any file for this at all.

[artemrys]

The UI repo was migrated, can you please open another PR for UCC generator repository?