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

User Can Accept Shares from Other Users #19153

Closed
MTRichards opened this issue Sep 18, 2015 · 19 comments
Closed

User Can Accept Shares from Other Users #19153

MTRichards opened this issue Sep 18, 2015 · 19 comments

Comments

@MTRichards
Copy link
Contributor

MTRichards commented Sep 18, 2015

User Accept Shares: As a user, I want to confirm acceptance of files shared with me before I add them to my account so that I can ensure audit controls (based on notifications app)
Acceptance Criteria:

  • This confirmation is optional, and the overall capability is an on/off switch in the admin panel
  • When files are shared, the owners checks a box “confirm acceptance” which sends a notification and waits on an acceptance of the share
  • If the share is accepted, it appears in the recipients account.
  • If the share is not accepted, the share owner is notified in their activity stream.
@MTRichards MTRichards added this to the 9.0-next milestone Sep 18, 2015
@PVince81
Copy link
Contributor

@schiesbn @jancborchardt this was discussed a long time ago 😄

@jancborchardt
Copy link
Member

Yup, as already mentioned way back in #4437

When files are shared, the owners checks a box “confirm acceptance” which sends a notification and waits on an acceptance of the share

Not another one of these options though – at least not being the default. Shares should always need to be accepted, for reasons of storage space, unexpected files turning up in your account etc. Yes maybe we’ll have a special option or plugin which allows people to force shares, but an option like this is not needed by default.

Part of this is also having the overview page of pending & rejected shares: #13495

cc @owncloud/designers

@MTRichards MTRichards modified the milestones: backlog, 9.0-next Oct 5, 2015
@cdamken
Copy link
Contributor

cdamken commented Feb 9, 2016

@MTRichards

00004636

@PVince81
Copy link
Contributor

PVince81 commented Feb 9, 2016

This could also solve some performance issues: whenever a share is created, there is code that will try and resolve file name conflicts for example if you received a folder "test" but already had a folder with this name locally. The conflict resolution can be slow when sharing with big groups.

If every user needs to accept their share separately, the resolution can be done at that time instead of at the time the share is created.

Is that actually still the case in 9.0 though ? @rullzer @schiesbn

@MTRichards
Copy link
Contributor Author

This is a pretty big feature, but certainly one that has been out there for a long time. Interested in the state in 9.0, and also with federated sharing in 9.0, then we can discuss if we want to do this / how we want to do this.

There are plenty of use cases where this is not wanted or needed, and some where it is wanted.

@MTRichards
Copy link
Contributor Author

I agree completely with this statement above:

Not another one of these options though – at least not being the default. Shares should always need to be accepted, for reasons of storage space, unexpected files turning up in your account etc. Yes maybe we’ll have a special option or plugin which allows people to force shares, but an option like this is not needed by default.

We do have lots of users who are happy without this feature, and we can't change the default behavior, or clutter it up, and yet this is asked for from time to time.

@rullzer
Copy link
Contributor

rullzer commented Feb 9, 2016

@PVince81 it is better in 9.0... but not completely solved.

@MTRichards for now the behaviour is the same as in 8.2 et al. So federated shares need to be accepted. While user/group shares just appear. There will need to be code changes to accept all shares. But with the new sharing code in place we at least know where to look ;)

I do however agree with @jancborchardt that there needs to be 1 default. Configuring this with options is asking for trouble. I also feel more that an app could take care of this then (some hook is thrown already that could set the accepted state) or something.

So long story short. 9.0 has the same behaviour as before.

@MTRichards
Copy link
Contributor Author

Great, thanks - we can discuss when we get around to planning for 9.1, if it makes the priority cut.

@PVince81
Copy link
Contributor

This would fit well with the proposed overview page for accepted/pending/rejected shares (local and remote): #13495

@butonic
Copy link
Member

butonic commented Nov 21, 2016

came up again

@PVince81
Copy link
Contributor

PVince81 commented Dec 6, 2016

@pmaier1 @felixboehm I'd like to move this to backlog for now, there is no time for this in 9.2.

Very rough estimate 10-15 md.

@pmaier1
Copy link
Contributor

pmaier1 commented Dec 6, 2016

Probably also related to this https://github.com/owncloud/platform/issues/44.
As it is no dependency for the agreed upon items for the next release I think you can do so. @butonic what does 'came up again' mean? by whom? Anyway, this should not fall into oblivion and be discussed for the following release.

@PVince81 PVince81 modified the milestones: backlog, 9.2 Dec 6, 2016
@PVince81
Copy link
Contributor

PVince81 commented Dec 6, 2016

Moving to backlog then.

Since this is a public ticket I'll just mention that the platform ticket above is about owncloud/android#1676 and owncloud/ios-legacy#656 to have mobile accept federated shares through notification apis

@PVince81
Copy link
Contributor

  • need pending indicator for sharer in the share list panel

@PVince81 PVince81 self-assigned this Dec 18, 2017
@PVince81
Copy link
Contributor

@PVince81
Copy link
Contributor

WIP PR: #30106

@PVince81
Copy link
Contributor

PVince81 commented Jun 7, 2018

waiting for #31613

@PVince81
Copy link
Contributor

PVince81 commented Jun 8, 2018

merged, will be released in 10.0.9

@lock
Copy link

lock bot commented Jul 30, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants