Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New share provider: Share by mail #657

Merged
merged 19 commits into from
Nov 2, 2016
Merged

New share provider: Share by mail #657

merged 19 commits into from
Nov 2, 2016

Conversation

schiessle
Copy link
Member

@schiessle schiessle commented Jul 29, 2016

This introduces a new share provider called "Share by mail" which allows you to enter a email address to the share dialog and send a personalized link.

share-by-mail

This is work in progress, but at least the auto-complete function works already.

Fix #1703

@schiessle schiessle added this to the Nextcloud 11.0 milestone Jul 29, 2016
@mention-bot
Copy link

@schiessle, thanks for your PR! By analyzing the annotation information on this pull request, we identified @rullzer, @blizzz and @nickvergessen to be potential reviewers

@schiessle
Copy link
Member Author

@jancborchardt I'm sure that's also interesting to you 😉

@nickvergessen
Copy link
Member

missing from shipped.json

@rullzer
Copy link
Member

rullzer commented Jul 29, 2016

While I think the idea is good. The UX there is terrible. Basically it should fall back to sending the e-mail if no remote is found.

/*
* Check if file is not already shared with the remote user
*/
$alreadyShared = $this->getSharedWith($shareWith, self::SHARE_TYPE_REMOTE, $share->getNode(), 1, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHARE_TYPE_EMAIL?

@icewind1991
Copy link
Member

The share provider looks like a lot of duplicate code from the other share providers, probably worth it having a go at factoring out the common logic

@jancborchardt
Copy link
Member

@schiessle awesome! :) Great that you’re pushing this!

I tend to agree with @rullzer – it’s a bit strange at the moment that you need to decide between remote and email. It should check automatically if a remote by that ID exists – if not share via email.

Also, can we tune that dropdown so that to the left of the remote user it shows their avatar (or colored circle with initial) and next to email it shows an email icon? Or do we need to do a major rewire for that?

@schiessle
Copy link
Member Author

schiessle commented Jul 29, 2016

The share provider looks like a lot of duplicate code from the other share providers, probably worth it having a go at factoring out the common logic

yes, that's mainly copy&pasted from the federated share provider... This will change a lot, you can ignore it for now

@schiessle
Copy link
Member Author

schiessle commented Jul 29, 2016

I tend to agree with @rullzer – it’s a bit strange at the moment that you need to decide between remote and email. It should check automatically if a remote by that ID exists – if not share via email.

I'm not sure. This would mean that you would first hand the share to the federated share provider, which would try to create a share. If it fails it would return to the share manager which would then try to do a mail share. But it could also happen that it is a federated share id and the server is just temporarily not available. In this case it would make more sense to re-try it later (with a background job) instead of falling back to email which will fail because for most user email address and federated share ID will not be the same. Such a behavior is also completely in-transparent to the user. I tend to let the user explicitly decide what he want to do. In case we find a exact match of a federated share or a email address we can hide the other option because it is really unlikely that a user has the exact same email address and federated cloud id. But if we enter something for the first time I would just let the user chose.

Also, can we tune that dropdown so that to the left of the remote user it shows their avatar (or colored circle with initial) and next to email it shows an email icon? Or do we need to do a major rewire for that?

We don't have a avatar if your share with a user for the first time... Let's keep this for later. This is out of scope for this PR.

@jancborchardt
Copy link
Member

I tend to let the user explicitly decide what he want to do.

Nextcloud tends to do stuff automatically. ;) If you share something with me via email – either cause my server is not available or you don’t have my federated cloud ID – it could be added to my Nextcloud as a federated share and communicated back to your server like that. Just automatically, there should be no difference and there doesn’t need to be, because in both cases you have the control over if I »can edit« or not.

@MariusBluem
Copy link
Member

MariusBluem commented Jul 29, 2016

Uhmm ... Isnt this covered by owncloud/core#25576
It seems to be something different ... but ... a bit ... the same 😁

@schiessle
Copy link
Member Author

schiessle commented Jul 29, 2016

Nextcloud tends to do stuff automatically. ;) If you share something with me via email – either cause my server is not available or you don’t have my federated cloud ID – it could be added to my Nextcloud as a federated share and communicated back to your server like that.

Unfortunately it is not that easy 😉 If I entered your cloud ID and your server is offline I can't send it to you by mail because in most cases both are not the same. And I will never know that sending the email failed.

Let me try to illustrate the two possible scenarios if we try to make it automatically:

  1. We first try to do a federated share. If it succeed fine. But what do we do if it don't succeed? If we know it is a federated share ID we can retry it and the recipient will receive his share once his Nextcloud is back online -> everything is fine. If we try to be more intelligent as the user we would fall back to a mail share, we would send the mail to the cloud ID. The delivery will fail because in most cases the cloud ID is not a email address at the same time. We will have no chance to detect that sending the mail failed. The user who send the share will see it in his share list and assume that everything is fine because he entered a federated cloud id. -> this is a problem you can't solve.
  2. So we could try to do it the other way around, first try to send a mail. If it is a valid mail address everything fine. If the rare case happens (0.1%) that a user has the same federated cloud ID as email address this would be bad because he would never receive a federated share but always a email. But it is just 0.1% so let's ignore it for now. Let's assume the ID was a cloud ID, we tried to send a mail and will not have any response that we failed to deliver the mail successfully, so we never know if we should retry a federated share -> solution is not feasible at all.

So we have two solutions to automate it and both don't work.

@schiessle
Copy link
Member Author

schiessle commented Jul 29, 2016

Uhmm ... Isnt this covered by https://github.com/owncloud/core/25576

@MariusBluem link doesn't work

@MariusBluem
Copy link
Member

MariusBluem commented Jul 29, 2016

Was updated 1 minute later 😒 ... The /pull/ was missing 😉 @schiessle

@schiessle
Copy link
Member Author

schiessle commented Jul 29, 2016

@Mar1u5 As you said, it is something different. I don't want to have a way to share a public link by mail, this is already today possible. But to create multiple public links, one for each recipient transparent in the share dialog

@jancborchardt
Copy link
Member

cc @Rocco83 because this is the »generate unique link per email address so revocation on a per-person basis is possible« feature you are interested in. :)

@jancborchardt
Copy link
Member

@schiessle any progress on this? Do you need any help or reviews? :)

@jancborchardt jancborchardt added the design Design, UI, UX, etc. label Oct 18, 2016
@schiessle schiessle force-pushed the share-by-mail branch 2 times, most recently from 367298e to 7384940 Compare October 24, 2016 15:19
Signed-off-by: Bjoern Schiessle <[email protected]>
email address we only return the exact match. It is highly unlikely
that the exact same email address and federated cloud id exists

Signed-off-by: Bjoern Schiessle <[email protected]>
Signed-off-by: Bjoern Schiessle <[email protected]>
Signed-off-by: Bjoern Schiessle <[email protected]>
Signed-off-by: Bjoern Schiessle <[email protected]>
…hare provider is enabled

Signed-off-by: Bjoern Schiessle <[email protected]>
Signed-off-by: Bjoern Schiessle <[email protected]>
Signed-off-by: Bjoern Schiessle <[email protected]>
@schiessle
Copy link
Member Author

We need to adjust this provider also for #339 Depending on which one goes in first.

Done. I also added a lot of unit tests (cc @LukasReschke)... Final review round 😉

@rullzer
Copy link
Member

rullzer commented Nov 2, 2016

I'd say lets get this in 👍

@LukasReschke
Copy link
Member

LGTM

@LukasReschke
Copy link
Member

LukasReschke commented Nov 2, 2016

@nickvergessen Your call now ;)

@nickvergessen
Copy link
Member

Yeah lets do that...

@nickvergessen nickvergessen merged commit 7da3ba3 into master Nov 2, 2016
@nickvergessen nickvergessen deleted the share-by-mail branch November 2, 2016 10:04
MorrisJobke added a commit that referenced this pull request Apr 11, 2017
* now handled by sharebymail app
* see #657

Signed-off-by: Morris Jobke <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review Waiting for reviews design Design, UI, UX, etc. enhancement feature: sharing
Projects
None yet
Development

Successfully merging this pull request may close these issues.