fix(FilesDropPlugin): Ensure all request for file request have a nickname

[provokateurin]

Follow-up to #55800

I just noticed there is also another bug with file drop: You can't upload folders, because it will tell you that a nickname is required. So MKCOL is fine without a nickname, as long as it's not for a file request. This is also reproducible on master before the other PR was merged.
I removed the check and simply ensured that all requests on a file request need to have the nickname set. Before this logic was intertwined with the MKCOL logic which lead to these issues.

[skjnldsv]

I just noticed there is also another bug with file drop: You can't upload folders, because it will tell you that a nickname is required.

This is exactly the design.
If you want to upload folders, you need a nickname.

[passibe15]

This is exactly the design.
If you want to upload folders, you need a nickname.

Why specifically for folders? Why isn't it also required for uploading individual files?
Also: Why specifically for file-drop share links? For non-file-drop share links, I can upload folders without a nickname just fine.

Apart from these inconsistencies, this is, in general, a pretty user-unfriendly requirement and it should be removed (or should never have been implemented in the first place).

Also, the error-handling is atrocious. Right now, I need to tell everyone "oh, by the way, if you want to upload folders, you need to set a nickname". I need to take extra time to explain this because there isn't even a pop-up that tells you a) the reason the upload failed and b) immediately prompts you to set a nickname. If that were the case, all of this might be on the very edge of being ok, but even then it still wouldn't explain the inconsistencies mentioned above.

I am honestly baffled by

1. these design decisions as well as
2. the lack of consideration for documentation and error handling, i.e. implementing such a requirement that is not documented anywhere (ok, it can happen) but then at the very least not even implementing proper error handling.

Still – I want to reiterate, just to be clear – documenting this or improving error handling does not justify this requirement existing in the first place.

EDIT: At the very least: Add proper error handling and then make it configurable. If people, for whatever reason, want to force everyone to set a nickname, when creating a link, there should be a checkbox "force nickname" plus a setting whether this checkbox is checked by default or not/user configurable or not.

[skjnldsv]

immediately prompts you to set a nickname

Would you feel more confortable if we enforced this ? @passibe15
Thanks for your interest on the matter, we take those feedback seriously.

To give you insight on the background for this decision, its a mix between new features and legacy behaviour.

[passibe15]

Thanks for the response!

Would you feel more confortable if we enforced this ?

I am not sure if "enforce" is the correct term here, as, in my view, this policy is already enforced by uploads always failing if a nickname is not set. As I have already explained, imo this (strictly) relates to proper error handling, i.e. explaining to the user why the upload failed and immediately offering a remedy.
But yes, I would be much more fine with that being done compared to the status quo.
Again, I don't really understand how something like this was implemented but no one thought about the UX/tested this in their own browser, noticing the lack of transparency vis a vis the user, but well …

With the current constraints, I believe the different scenarios should be handled as follows:

1. Uploading a file
   • Nothing special happens, the file just gets uploaded
2. Uploading a folder
   • Message appears that nickname must be set
   • User is immediately prompted to set a nickname

---

its a mix between new features and legacy behaviour

Is it planned to remedy this at some point?
The reasoning in the comment of the offending code is simply:

// This prevents confusion when uploading files and help
// classify them by uploaders.

If those are the only reasons why a nickname is necessary, as I've said, this should, at the very least, be made configurable, i.e. letting me decide if I want to classify folders by uploaders or if I am fine with not classifying and the possible confusion following from that decision.

[skjnldsv]

this policy is already enforced by uploads always failing if a nickname is not set.

Yes, that is a bit counter-intuitive!
We could prevent picking folders if no nicknames are set, etc etc, but to be honest, I'm more and more leaning towards making things simpler. We made a mistake trying to keep both behaviours when we added the File Request feature (imho), and should have just standardisez having a nickname set no matter what.

Is it planned to remedy this at some point?

I'll push this internally, we'll see.

[skjnldsv]

If those are the only reasons why a nickname is necessary, as I've said, this should, at the very least, be made configurable, i.e. letting me decide if I want to classify folders by uploaders or if I am fine with not classifying and the possible confusion following from that decision.

Initial file drop refused ALL folders, for security reasons.
Everything was flattened, see discussion on #15921

Second addition was File request, which enforced the request for a nickname and basically put everything in a subfolder names with your nickname

Lastly, we added support for folders upload, but to avoid the insane conflicts resolution and so on, we kept the original behaviour that if you want to upload many files/folders at once, it's best to have them within your nickname folder, thus asking for a nickname if you want to upload folders.
Else everything gets flattened and the owner of the share would have no way of knowing what is what (also, very easy to upload a folder with 10k random files and make things very hard to handle, while the nickname makes it easy to delete if spam/unwanted

[provokateurin]

This is exactly the design.

Ok I see. I just thought this was wrong, because the UX is horrible: You see the error notification with the technical description and no way to enter the nickname in the dialog. This seemed really unexpected to me, so was thinking that this is not intended.

[provokateurin]

Ok, so with this PR chunked upload for public shares is enabled again and works in all scenarios.

I also changed a bit how file drops work:
In a file request, you always have to enter a nickname.
In a file drop, you never have to enter a nickname (not even for uploading folders like before).

I think requiring a nickname for uploading folders on a file drop is a strange requirement, because you can still upload identically named files which are not distinguishable. So it would only make sense to require a nickname for files as well, but we have file requests for that. Besides that the UX was terrible, so that is gone as well now.

With this, the distinction between a file drop and a file request is much clearer and the users are able to choose which one they want.
The plugin could really be cleaned up further, but at least it all works now.

[provokateurin]

This needs a backport for stable32, but I'll include that in #55804.

[passibe15]

I think requiring a nickname for uploading folders on a file drop is a strange requirement, because you can still upload identically named files which are not distinguishable. So it would only make sense to require a nickname for files as well, but we have file requests for that. Besides that the UX was terrible, so that is gone as well now.

THANK YOU!

[skjnldsv]

With this, the distinction between a file drop and a file request is much clearer and the users are able to choose which one they want.

to be fair, they should probably just be merged together at some point 🙈

[provokateurin]

Absolutely, also because the naming is super confusing and inconsistent 😅

[skjnldsv]

Absolutely, also because the naming is super confusing and inconsistent 😅

With 31, the design team asked for file drop to be entirely renamed like file request

[provokateurin]

Cypress failure is unrelated

[come-nc]

We should merge together and have a checkbox option to require a nickname, no? (no nickname required == file drop).

Because to me it sounds useful to have both file request and file drop it’s not the same usecases. The issue currently is that both are named the same in the UI and the workflow is not always consistent.

[provokateurin]

Yes yes, I just want to fix the problems first though 🙈