You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes when uploading a file, the type of the file is set to the type that was appropriate for the previous upload performed by that user, rather than what is suitable for this folder.
Unfortunately, I don't have the exact steps needed for a reproduction scenario, but I've seen this bug happen often enough that I feel I should document it here.
Incomplete reproduction steps
User navigates to a folder that has allowed types configured to contain exactly 1 value, e.g. acme:commonDocument
User uploads a file, gets prompted with a metadata panel and fills it out. The file is automatically converted to type acme:commonDocument
User navigates to a different folder that does not have allowed types configured
The call to uploader-plus/allowed-content-types?destination=… returns { "types" : null }
User uploads a file and is not prompted with a metadata panel
Expected behaviour
The uploaded file is of type cm:content
Observed behaviour
The uploaded file is of type acme:commonDocument
The text was updated successfully, but these errors were encountered:
Thanks for raising this issue Roel, I will try to have a look at it during the weekend. Meanwhile do not hesitate to post any updates or further analysis.
On 3 Jun 2019, at 15:53, rschev ***@***.***> wrote:
Sometimes when uploading a file, the type of the file is set to the type that was appropriate for the previous upload performed by that user, rather than what is suitable for this folder.
Unfortunately, I don't have the exact steps needed for a reproduction scenario, but I've seen this bug happen often enough that I feel I should document it here.
Incomplete reproduction steps
User navigates to a folder that has allowed types configured to contain exactly 1 value, e.g. acme:commonDocument
User uploads a file. It gets automatically converted to type acme:commonDocument
User navigates to a different folder that does not have allowed types configured
The call to uploader-plus/allowed-content-types?destination=… returns { "types" : null }
User uploads a file
Expected behaviour
The uploaded file is of type cm:content
Observed behaviour
The uploaded file is of type acme:commonDocument
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Sometimes when uploading a file, the type of the file is set to the type that was appropriate for the previous upload performed by that user, rather than what is suitable for this folder.
Unfortunately, I don't have the exact steps needed for a reproduction scenario, but I've seen this bug happen often enough that I feel I should document it here.
Incomplete reproduction steps
acme:commonDocument
acme:commonDocument
uploader-plus/allowed-content-types?destination=…
returns{ "types" : null }
Expected behaviour
The uploaded file is of type
cm:content
Observed behaviour
The uploaded file is of type
acme:commonDocument
The text was updated successfully, but these errors were encountered: