REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.16
HARDWARE: Xperia 10
UI LANGUAGE: PL
REGRESSION: Don’t think so
DESCRIPTION:
NextCloud integration doesn’t accept multiple files passed as ShareAction.resources.
It always pick only first file from the list.
The same is also valid for Blueooth.
It seems only mail client works as expected.
All selected files properly shared like for example with mail as destination.
ACTUAL RESULT:
Already in step 5 we can see that Nextcloud sharing will show only one file
after passing step 6, only one file is uploaded for Nextcloud or Bluetooth,
it’s usually the first file from the ShareAction.resources list.
Patch: Project: GallerySharing is not required actually. This problem can be clearly seen with any other application that allows to share multiple items at once through the Sharing API. Yet I couldn’t find anything specific so I gave the simple possible use case for the bug.
Nope, this is a bug in NextCloud integration. Patch only expose it. There’s nothing wrong for example with E-Mail. It properly detects multiple selected files.
Hence it’s explicitly bug related to built in functionality as the ShareAction.resources officially accept an array.
Your bug report is about a patch, so either report it on github to the author of the patch, or a feature request for jolla to incorporate this feature (patch included)
I’m sorry but could you please read one more time this bug report? I did update description a bit.
Please keep in mind that I’m the author of the patch and I found a bug in NextCloud integration while I was creating this patch.
There is nothing I can fix on my own it’s a problem with NextCloud integration.
I explicitly mentioned that there’s no problem if you pick up mail as a destination for sharing.
Seems to only work with email? Bluetooth, single file, random android app, doesn’t work at all, dropbox, single file again… It’s a feature request from what I can tell
well thank you for the information. I didn’t check Bluetooth. I’ll add this to the bug report.
I’ll repeat one more time. It’s not a feature request. I’m not doing anything that’s not handled by the official documentation. If you can point me to official information that says that I can’t share multiple files using Bluetooth or Nextcloud through Sharing API then I’ll consider this as a feature request. Otherwise if mail works fine, then it means BT and Nextcloud should be fixed to be in line with mail or shouldn’t be shown in the sharing api window when ShareAction.resources is populated with more than one element.
Can you point me where it says it will support a list? If share.action supports lists but only email accepts them (which is why it supports lists in the first place), you patching adding lists to recipients that do not support them (yet maybe? Maybe a feature???) is not a bug, feature request
No, where did you came up this from? I’m using official api the way it was designed. I have no control over what’s happening with it later. It’s simple, just file up an array and call trigger() the rest is handled by the OS.
Oh and btw I’m not sure if single bt transfer from a list was caused by list or windows receiving, so probably bad to include it in this bug report, might work on linux, might work with different list implementation (could work from file manager? No idea), throwing into a bug report with 0 info is just bad manners
Yes, lists are supported and it was passed, emails can process them and handle multiple attachments other recipients won’t and will process one item per call, ignoring your list, you have to feed them one by one, or request a feature for a recipient to handle more than one item (you could have a share plugin for imgur or youtube and they won’t accept 20gb of your videos folder as a list, you can’t force apis to do extra functionality just because you sent more items, but shareapi supports lists, bug)
no no no, there’s no mention in the docs that I should bypass api functionality. If that’s not allowed then ShareAction.resources should accept only single element. Instead it accepts many so it’s up to the receiver to do it’s job and in this case NextCloud and Bluetooth are not doing their job while mail is doing. So it’s a bug, a left over. It would be different if I’d ask to change the shareaction.resources to accept multiple files but right now it already does this and it’s not on my side of the app to handle the situation you’re describing.
So in your case - uploading GB of data, a share plugin should handle the workload and not the sender and this is the case this time. The receiver/share plugin is not doing it’s job properly as the system was designed.
What bypass? Sharing api allows sending lists - does what it says in the docs.
Not all sharing api recipients handle multiple files - share 5 videos to a tv recipient, is it going to show 5 screens at once? It will ignore 4 and play 1 of them, BUG
of course it’s a bug, It should queue all of them and play one after another. But it’s a task for receiver not for the sender. As the sender has no idea who will receive what he is sending.
I’ll repeat it one more time. When sending data using ShareAction.resources I have no idea who will receive the list and I expect the system will handle this properly and won’t allow the user to pick up destination that doesn’t accept multiple items. That’s simple and clear. Then Bluetooth and NextCloud should either:
get support for multiple files
doesn’t show in the sharing dialog
Right now nothing of this happen, so it’s a bug. I propose how it should be fixed cause there’s no problem from handling it that way as:
bluetooth can easly handle multiple file sending - other phones even the first smartphones has this feature
nextcloud - is just a cloud so there’s no limit at all
Thank you, it’s a feature, nowhere in the OS can you share multiple files to them, which is a conscious decision, the fact that sharing api can handle lists (for email only it seems?) does not mean that all recipients hndle them which is your assumption, you just shove a list and expect every possible receiving api to just handle it, invent a playlist or a queue on the fly as we go
@throwaway69, the API documentation clearly states that a “list of resources” (URLs and strings) can be provided. AFAIR this never worked for Bluetooth, hence @lolek is also right, that is very likely not a regression, but a longstanding issue. Also note, that the example section in Jolla’s documentation explicitly discusses transmitting multiple “resources”. Plus the caller cannot know which target / sink the user chooses, so this must work generically for all supported sinks, not just “email”.
The workaround is easy, the code using this API call can perform a call for each “resource” to be transmitted. But according to the documentation that should not be necessary.
@lolek, please mind that bulk transfers (if they work) generally have a drawback: If something fails during the bulk transfer (not at its start), it is not easy to design a UI for potentially very long lists of “resources”, which properly informs the user what happened, i.e., what is already transferred, what exactly failed why, and which “resources” were not transmitted (or it may simply carry on and continue to transfer as many “resources” as possible). Practically, you may be better off handling this with your own code. Nevertheless, I concur that the API does seem to not work as described.
@throwaway69 actually when I though more about this workaround, in the case of Bluetooth and Nextcloud the use of it is unacceptable cause it would only potentially cause user frustration and would make sharing with mail totally unusable.
It’s because right now, when you want to share something over BT, additional dialog popups which ask for a target. The same is also valid for NextCloud where you have to specify destination.
Now imagine, user select ten files then the user would need, select ten times destination for the share and in case of NextCloud or BT he would need to again select ten times of destination in case of BT while in case of NextCloud we could assume that he will just confirm previous destination.
But then mail destination would suffer and be probably impossible to handle as right when you select mail as a target, a mail client is opened, means that it would require opening ten new mail windows. Is that even possible? And that’s unavoidable with this solution because as it has been explained by me, and by @olf the sender has no idea what will be the target. So there’s no way to know in advance what functionalities will be supported by the target. It’s up to the target/share plugin to properly handle this.
Yes this is how it should be handled. It should proceed with the items from the list one by one and in case of a single failure it should:
in case of failure that’s strictly related to the file like unable to read source - continue with the rest and throw notification
in case there’s failure related with the target like - lost connection - totally stop proceeding the list.
There may be some other possible solution, either way is fine as long as user will be able to find out why each item failed.
FYI: there’s this comment in GalleryGridPage.qml:
// TODO: Not sure how we should deal with the error cases e.g. file couldn’t be deleted and
// we don’t even have a design for that yet.
which is related to your concern. Tbh right now the design is already there. Just throw info to the notification and it will show all failures the same way as it’s done right now which is the even screen (I hope it’s the correct name for that part of the system). Probably it is some really old comment which has been forgotten.
