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
ocsEntryToNode expects that the OCS entry contains a mimetype field and a file_source field. However, remote shares may not provide them. Due to that, the remote shares are not shown in the Share views.
Short version:
If the remote share is pending there is no mimetype nor file_source
If the remote share is accepted there is mimetype but no file_source; file_source is instead returned as file_id
Once accepted a real mountpoint is set for remote shares, so the mimetype and the fileid become available. However, the fileid is returned as file_id instead of file_source.
Bug description
ocsEntryToNode
expects that the OCS entry contains amimetype
field and afile_source
field. However, remote shares may not provide them. Due to that, the remote shares are not shown in the Share views.Short version:
mimetype
norfile_source
mimetype
but nofile_source
;file_source
is instead returned asfile_id
Longer version:
Remote shares have several base fields which are then extended from the information of the file based on its mountpoint.
However, when pending remote shares are got they are not extended with those extra fields (as they may be still using a temporary mountpoint), so the mimetype is not available.
Once accepted a real mountpoint is set for remote shares, so the mimetype and the fileid become available. However, the fileid is returned as
file_id
instead offile_source
.@skjnldsv FYI
Steps to reproduce
Steps to reproduce (scenario 1)
Expected result
The pending remote share is shown
Actual result
The pending remote share is not shown; browser console shows
Error while parsing OCS entry
with errorMissing or invalid mandatory mime
Steps to reproduce (scenario 2)
Expected result
The accepted remote share is shown
Actual result
The accepted remote share is not shown; browser console shows
Trying to update/set a node without fileid
Expected behavior
See above
Installation method
None
Nextcloud Server version
master
Operating system
None
PHP engine version
None
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: