DNNCommunity
Download type has no "none selected" default, nor a way to un-associate a file
Describe the bug
Add a field of type "Download". On the next record you add or edit, in the spot where you select the file to link to, you'll see a file selector with the folder set to "root" and the file set to the 1st file alphabetically in your root folder. There's no "please select" or "none selected" to indicate that for this record there is no file to link to. When you save the record, that 1st file will be associated with the record.
To Reproduce
- add a record of type "download"
- edit an existing record or add a new record (either produce the same problem)
- save the record
- the 1st file in the root will be associated with this record. there's no way to have no file associated with the record.
Expected behavior
If the 1st choice in the file list is "none selected", and if upon saving there would be no file associated with the record, that would be good. I've also seen other techniques like photo in the profile editor where there's a button to delete associated photo. that'd be ok too.
We are currently moving from Evoq Basic to DNN Platform and are running into this issue. On our Evoq servers the Form and List Download fields behave correctly, allowing "none selected". On the DNN Platform servers the Download field drop down does not have a "none selected" option, exactly like dgingold reported. Seeing that this issue has existed for almost 2 years I have to ask if anything is being done about it, and if there is an estimate on a fix.
We are currently moving from Evoq Basic to DNN Platform and are running into this issue. On our Evoq servers the Form and List Download fields behave correctly, allowing "none selected". On the DNN Platform servers the Download field drop down does not have a "none selected" option, exactly like dgingold reported. Seeing that this issue has existed for almost 2 years I have to ask if anything is being done about it, and if there is an estimate on a fix.
The issue remaining open for any length of time after the bug being verified only means that there hasn't been a developer impacted or approached to implement the necessary updates and submit them back to the project. As soon as someone gets approached by a sponsor, or a developer needs to fix this for themselves,
I'm sure it will be resolved at some point.
Sorry for the mildly good news... :)
We recently upgraded and am experiencing the same situation. Any idea when this may get resolved? Is there a workaround that anyone has used that might be helpful?
