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:
@schiesbn @jancborchardt this was discussed a long time ago :smile:
Yup, as already mentioned way back in https://github.com/owncloud/core/issues/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: https://github.com/owncloud/core/issues/13495
cc @owncloud/designers
@MTRichards
00004636
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
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.
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.
@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.
Great, thanks - we can discuss when we get around to planning for 9.1, if it makes the priority cut.
This would fit well with the proposed overview page for accepted/pending/rejected shares (local and remote): https://github.com/owncloud/core/issues/13495
came up again
@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.
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.
Moving to backlog then.
Since this is a public ticket I'll just mention that the platform ticket above is about https://github.com/owncloud/android/issues/1676 and https://github.com/owncloud/ios/issues/656 to have mobile accept federated shares through notification apis
waiting for https://github.com/owncloud/core/pull/31613
merged, will be released in 10.0.9
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.