Group shares with same source and target #25113

Merged
merged 7 commits into from Jul 19, 2016

Projects

None yet

5 participants

@rullzer
Contributor
rullzer commented Jun 15, 2016 edited

Fixes #24575

Note that this is a very limited solution and eventually we want smarter
merging!

TODO:

  • Add intergration tests
  • Check if permissions are properly accumulated
  • Check if javascript needs to be fixed

CC: @PVince81 @jonasheinisch

@rullzer rullzer added this to the 9.1-current milestone Jun 15, 2016
@mention-bot

By analyzing the blame information on this pull request, we identified @icewind1991, @schiessle and @bartv2 to be potential reviewers

@rullzer
Contributor
rullzer commented Jun 15, 2016

Mmmm seems the js side needs more fixing...

@PVince81
Collaborator

Wasn't there such logic already in the past ? Or did it get discarded through refactorings ?

@PVince81
Collaborator

@icewind1991 do you remember anything ?

@rullzer
Contributor
rullzer commented Jun 15, 2016

Yes there was such logic. But it had to be discarded for various reasons.

  • We can't group shares in the providers as there is no (future) guarantee that the current provider division is true for all installations
  • We can't group shares in the providers since we support pagination. So if you only request the first N shares what to do.

At the same time I think this logic is now in the place where it should be. In the sharedMount/sharedStorage. Since that is the actual place where we group stuff.

@PVince81
Collaborator

Doesn't help with #25186 which will need a different fix.

@PVince81
Collaborator

I don't know what to do with this. It feels a bit dangerous to merge that late.
Also, unit tests are missing.

@PVince81 PVince81 commented on an outdated diff Jun 27, 2016
core/js/shareitemmodel.js
}
model.set(model.parse({
shares: sharesMap,
- reshare: reshare
+ reshare: reshare,
+ reshares: reshares,
@PVince81
PVince81 Jun 27, 2016 Collaborator

don't add extra commas in JS, this used to break in IE

@PVince81 PVince81 commented on the diff Jun 27, 2016
apps/files_sharing/lib/SharedMount.php
@@ -106,7 +112,11 @@ private function verifyMountPoint(\OCP\Share\IShare $share, array $mountpoints)
*/
private function updateFileTarget($newPath, &$share) {
$share->setTarget($newPath);
- \OC::$server->getShareManager()->moveShare($share, $this->user);
+
+ foreach ($this->groupedShares as $share) {
@PVince81
PVince81 Jun 27, 2016 Collaborator

conflict with the "share" variable from the method argument.

Also I'm confused why we are relying on the internal groupedShares here and ignoring the $share attribute, the function doesn't fulfil its contract

@rullzer
rullzer Jun 27, 2016 Contributor

Ah fair enough.

Yeah it needs to be cleaned up more. Basically the groupedShares are always there now. The 'regual' share is just a super set of all shares. I did it this way so we have less code paths. So we even if you have just 1 incomming share then you will have a 'super' share with the same stuff. And groupedShares with just 1 entry.

I prefer 1 code path.

@PVince81
Collaborator
PVince81 commented Jul 7, 2016

Rebased

@PVince81 PVince81 modified the milestone: 9.2, 9.1 Jul 7, 2016
@PVince81
Collaborator
PVince81 commented Jul 7, 2016

Ouch, this breaks sharing: when opening the share panel it always says "Resharing not allowed" even for non-shared folders where I'm the owner.

@PVince81
Collaborator
PVince81 commented Jul 7, 2016 edited

Some test cases for later, where "user1" is in "group1" and "group2"

  • TEST: share folder "test" as outsider to "group1" and "user1" with same permissions
  • TEST: share folder "test" as outsider to "group1" and "user1" with different permissions
  • TEST: share folder "test" as outsider to "group1" and "group2" with same permissions
  • TEST: share folder "test" as outsider to "group1" and "group2" with different permissions
  • TEST: share folder "test" as outsider to "group1" and "group2" and "user1" (why not!) with different permissions
  • TEST: share folder "test" as "user1" to "group1"
  • TEST: share folder "test" as "user1" to "group1" and "group2" with same permissions
  • TEST: share folder "test" as "user1" to "group1" and "group2" with different permissions

Most of these gave me two folders on v9.0.3 so let's hope this PR covers them all ๐Ÿ˜„

@PVince81
Collaborator
PVince81 commented Jul 7, 2016

After reverting the JS commit locally I'm able to share again, so something to look into.

I did a quick test with the different grouping cases and it seems to work nicely ! Great job !

The hardest part: write integration tests for them.

@PVince81
Collaborator
PVince81 commented Jul 7, 2016

@rullzer any reason for the JS fix ? Without the JS there is no duplication in the "Shared with others" and "Shared with you" entries. Unless I missed a case ?

@PVince81
Collaborator
PVince81 commented Jul 7, 2016

ah, reshares.. forgot those ๐Ÿ˜ฆ

@PVince81
Collaborator
PVince81 commented Jul 11, 2016 edited
  • TODO: need repair step to recombine the wrongly duplicated folders (even if they were manually excluded as a workaround)

Sounds like fun.

@PVince81
Collaborator
PVince81 commented Jul 11, 2016 edited
  • TEST: unshare from self for a grouped entry, which one is affected ? => both
  • TEST: reshare grouped entry => creates a new independent entry
@PVince81 PVince81 self-assigned this Jul 11, 2016
@rullzer
Contributor
rullzer commented Jul 11, 2016

TODO: need repair step to recombine the wrongly duplicated folders (even if they were manually excluded as a workaround)

Sounds like fun.

It is actually not that hard.
The fun part is deciding if you want ot merge all? Or just the ones still marked as dups ( (2), (3) ) etc.

@PVince81
Collaborator

@rullzer ideally repair it to make it work just like it did in 8.2.6.
So all non de-duplicated entries are there for such cases, repair them to be merged properly.

@PVince81
Collaborator

Added integration tests to match the cases from #25113 (comment)

@SergioBertolinSG check this out, I used some regexp magic to make some sentences more flexible

@PVince81
Collaborator

Oh, looks like I had an outdated version of the branch. The tests above actually pass and the integration tests will prove it.

@PVince81
Collaborator
PVince81 commented Jul 11, 2016 edited
  • TODO: add unit tests for the improved MountProvider logic
@PVince81 PVince81 commented on the diff Jul 11, 2016
apps/files_sharing/lib/SharedMount.php
@@ -61,10 +64,13 @@ class SharedMount extends MountPoint implements MoveableMount {
public function __construct($storage, array $mountpoints, $arguments = null, $loader = null) {
$this->user = $arguments['user'];
$this->recipientView = new View('/' . $this->user . '/files');
- $this->share = $arguments['newShare'];
- $newMountPoint = $this->verifyMountPoint($this->share, $mountpoints);
+
+ $this->superShare = $arguments['superShare'];
+ $this->groupedShares = $arguments['groupedShares'];
@PVince81
PVince81 Jul 11, 2016 Collaborator

I suppose another enhanced approach would be to define a new class CompositeShare that implements IShare and contains all the children (groupedShares) then when we call setTarget() on the main one it internally sets the target on all sub-shares.

This could have the advantage of being reusable in other contexts where grouping is required.

@rullzer
rullzer Jul 11, 2016 Contributor

I like that!
very elegant and abstract nicely away

@PVince81 PVince81 commented on the diff Jul 11, 2016
apps/files_sharing/lib/MountProvider.php
@@ -95,4 +100,63 @@ public function getMountsForUser(IUser $user, IStorageFactory $storageFactory) {
// array_filter removes the null values from the array
return array_filter($mounts);
}
+
+ /**
+ * @param \OCP\Share\IShare[] $shares
+ * @return \OCP\Share\IShare[]
+ */
+ private function groupShares(array $shares) {
+ $tmp = [];
+
+ foreach ($shares as $share) {
+ if (!isset($tmp[$share->getNodeId()])) {
+ $tmp[$share->getNodeId()] = [];
+ }
+ $tmp[$share->getNodeId()][$share->getTarget()][] = $share;
@PVince81
PVince81 Jul 11, 2016 Collaborator

@rullzer Shouldn't nodeId and target be combined into a single key ? That is, if you're grouping by these too, unless this is doing something slightly different.

Once I understand this I'll update the PHPDoc.

@PVince81
PVince81 Jul 11, 2016 Collaborator

Seems it would likely yield the same results anyway.

Whenever a single folder is has two shares, one with group and one with user, as long as the target is the same they need to stay combined. Once the user renamed the target, they need to stay split. That makes sense.

@rullzer
rullzer Jul 11, 2016 Contributor

Yeah that is the 'old' behaviour anyways.

I'm not convinced that is always the right approach. Ideally I just see 1 entry per share. Else you also get duplicated data if you sync etc.

But lets make it behave like in the old days first.

@PVince81 PVince81 commented on an outdated diff Jul 11, 2016
apps/files_sharing/lib/MountProvider.php
@@ -95,4 +100,63 @@ public function getMountsForUser(IUser $user, IStorageFactory $storageFactory) {
// array_filter removes the null values from the array
return array_filter($mounts);
}
+
+ /**
+ * @param \OCP\Share\IShare[] $shares
+ * @return \OCP\Share\IShare[]
@PVince81
PVince81 Jul 11, 2016 Collaborator

so basically this is actually \OCP\Share\IShare[][], first level is group and second is list of shares within that group

@PVince81
Collaborator

@rullzer improved readability a bit, let me know whether this makes sense: 4c46b4a

More unit tests to come later for better coverage of the different cases.

@rullzer
Contributor
rullzer commented Jul 11, 2016

@PVince81 had a quick look. Looks good. Will have a deeper look after some sleep.

@rullzer
Contributor
rullzer commented Jul 12, 2016

@PVince81 after a night sleep. You fix indeed cleans it up! Thanks.

@PVince81
Collaborator

Working on the repair steps now.

I find the hardest part is to identify which to adjust and which to leave alone.

This is on 9.0: when share with group1, group2 and user1 (user1 is in group1 and group2)

MariaDB [owncloud]> select * from oc_share order by item_source, uid_owner, stime;
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+
| id | share_type | share_with | uid_owner | uid_initiator | parent | item_type | item_source | item_target | file_source | file_target   | permissions | stime      | accepted | expiration | token | mail_send |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+
|  1 |          1 | group1     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test         |          31 | 1468329809 |        0 | NULL       | NULL  |         0 |
|  6 |          2 | user1      | admin     | admin         |      1 | folder    | 9           | NULL        |           9 | /test (2)     |          31 | 1468329809 |        0 | NULL       | NULL  |         0 |
|  2 |          1 | group2     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test         |          31 | 1468329812 |        0 | NULL       | NULL  |         0 |
|  3 |          2 | user1      | admin     | admin         |      2 | folder    | 9           | NULL        |           9 | /test (2) (2) |          31 | 1468329812 |        0 | NULL       | NULL  |         0 |
|  5 |          0 | user1      | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test         |          31 | 1468329916 |        0 | NULL       | NULL  |         0 |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+

And here is when created on this branch:

MariaDB [owncloud]> select * from oc_share order by item_source, uid_owner, stime;
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+-------------+-------------+------------+----------+------------+-------+-----------+
| id | share_type | share_with | uid_owner | uid_initiator | parent | item_type | item_source | item_target | file_source | file_target | permissions | stime      | accepted | expiration | token | mail_send |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+-------------+-------------+------------+----------+------------+-------+-----------+
|  7 |          1 | group1     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test       |          31 | 1468330088 |        0 | NULL       | NULL  |         0 |
|  8 |          1 | group2     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test       |          31 | 1468330091 |        0 | NULL       | NULL  |         0 |
|  9 |          0 | user1      | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test       |          31 | 1468330095 |        0 | NULL       | NULL  |         0 |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+-------------+-------------+------------+----------+------------+-------+-----------+

However, it could happen that the user decided to rename (also on this branch):

MariaDB [owncloud]> select * from oc_share order by item_source, uid_owner, stime;
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+
| id | share_type | share_with | uid_owner | uid_initiator | parent | item_type | item_source | item_target | file_source | file_target   | permissions | stime      | accepted | expiration | token | mail_send |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+
|  7 |          1 | group1     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test         |          31 | 1468330088 |        0 | NULL       | NULL  |         0 |
| 10 |          2 | user1      | admin     | admin         |      7 | folder    | 9           | NULL        |           9 | /test renamed |          31 | 1468330088 |        0 | NULL       | NULL  |         0 |
|  8 |          1 | group2     | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test         |          31 | 1468330091 |        0 | NULL       | NULL  |         0 |
| 11 |          2 | user1      | admin     | admin         |      8 | folder    | 9           | NULL        |           9 | /test renamed |          31 | 1468330091 |        0 | NULL       | NULL  |         0 |
|  9 |          0 | user1      | admin     | admin         |   NULL | folder    | 9           | NULL        |           9 | /test renamed |          31 | 1468330095 |        0 | NULL       | NULL  |         0 |
+----+------------+------------+-----------+---------------+--------+-----------+-------------+-------------+-------------+---------------+-------------+------------+----------+------------+-------+-----------+

This looks very close to the bogus case that needs to be repaired.

So for now the idea is to first gather all shares with type "2" (children of group shares) and check whether they all have the same "target". If they do, it means it was a legitimate rename.
However, if the target is inconsistent, then set the target to the one of the parent.

@PVince81
Collaborator

and take into account the case where the user voluntarily deleted the double shares in 9.0 and restore them by setting their permissions back for proper grouping.

@PVince81
Collaborator
  • TODO: add some integration test cases for when the recipient renamed the target, make sure that the old target and no duplicates appear
@PVince81
Collaborator

Okay, turns out that a voluntary rename will cause one child entry for every group share.
While a bogus entry will only have a single child entry with a different name, attached to only one of the groups.

Bogus:

MariaDB [owncloud]> select id,uid_owner,item_source,share_type,parent,file_target,permissions from oc_share order by item_source, uid_owner, stime;
+----+-----------+-------------+------------+--------+-------------+-------------+
| id | uid_owner | item_source | share_type | parent | file_target | permissions |
+----+-----------+-------------+------------+--------+-------------+-------------+
| 12 | admin     | 9           |          1 |   NULL | /test       |          31 |
| 13 | admin     | 9           |          1 |   NULL | /test       |          31 |
| 14 | admin     | 9           |          2 |     13 | /test (2)   |          31 |
+----+-----------+-------------+------------+--------+-------------+-------------+

Legitimate rename:

MariaDB [owncloud]> select id,uid_owner,item_source,share_type,parent,file_target,permissions from oc_share order by item_source, uid_owner, stime;
+----+-----------+-------------+------------+--------+-------------+-------------+
| id | uid_owner | item_source | share_type | parent | file_target | permissions |
+----+-----------+-------------+------------+--------+-------------+-------------+
| 15 | admin     | 9           |          1 |   NULL | /test       |          31 |
| 17 | admin     | 9           |          2 |     15 | /test (2)   |          31 |
| 16 | admin     | 9           |          1 |   NULL | /test       |          31 |
| 18 | admin     | 9           |          2 |     16 | /test (2)   |          31 |
+----+-----------+-------------+------------+--------+-------------+-------------+
@PVince81
Collaborator

@rullzer here's a beginning a made before the realization in my former comment.

Did you have any fancy/clever ideas since it sounded like it would be easy ?
deca933

Maybe you were thinking of another approach like iterating over every user and then grouping for them using the same logic as in MountProviderTest ?

@rullzer rullzer and 1 other commented on an outdated diff Jul 12, 2016
lib/private/Repair/RepairUnmergedShares.php
+
+ // FIXME: also need to take "share_with" user into account to build a group !
+
+ $shareIds = [];
+ $targets = [];
+ $lastKey = null;
+ $maxPermissions = 0;
+ $mainShare = null;
+
+ do {
+ $resultsCount = 0;
+ $query->setFirstResult($offset);
+ $resultSet = $query->execute();
+
+ while (($result = $resultSet->fetch()) !== false) {
+ $key = $result['item_source'] . '/' . $result['uid_owner'];
@rullzer
rullzer Jul 12, 2016 Contributor

Each item only has 1 owner right?

@PVince81
PVince81 Jul 12, 2016 Collaborator

indeed, just wanted to be safe in case we have older unfixed reshares where the owner might be the sharer instead of the original owner

@PVince81
Collaborator

Looks like we'll also need to find group memberships.

Maybe my approach is wrong and we should iterate over users instead of over shares.

@PVince81
Collaborator
PVince81 commented Jul 12, 2016 edited
  • TODO: also need some testing with subfolder reshares (shares within a received parent folder)
@PVince81
Collaborator
  • TODO: exclude repair step if share provider is not the default one ?
@PVince81
Collaborator
PVince81 commented Jul 12, 2016 edited

@rullzer I completely revamped the repair step, please check it out.
That's quite some complex machinery.

Now it does the following

  1. Iterate over every user
  2. Get the subshares (SHARE_TYPE_USERGROUP)
  3. Get the group shares (SHARE_TYPE_GROUP)
  4. Get the user shares (SHARE_TYPE_USER)
  5. Group them by "item_source"
  6. Iterate over "item_source"
  7. For each set of shares (we consider all three types to be a single share entry)
  8. Check if the share is valid:
    • a valid share has one subshare that matches every group share
    • a valid share has the same "file_target" value in every subshare
    • the "file_target" can be different than the one from the group share (legitimate reshare) as long as every subshare has the same
  9. If the share is not valid, fix it
    • check whether the user opted out of ALL subshares by checking if all have permissions 0
    • set the "file_target" to the same value as the first group share
    • if user did not opt out of ALL and if "permissions" of a subshare is 0 (the user deleted one of the duplicates), restore the subshare to the permissions from the parent group share

Note that the "SHARE_WITH_USER" entry is treated like a subshare and also gets its "file_target" adjust.

Now I realize I missed something:

  • TODO: if the user opted out of ALL subshares (deleted all duplicates + the main share), then only adjust "file_target"

Edit: added missing case

@PVince81
Collaborator

I tested subfolder reshares and they are not affected. It doesn't cause any duplicate because the item inside "test/inside" and "test (2)/inside" is technically the same folder, same fileid, so any reshare created there will be in the correct format.

@PVince81
Collaborator

Okay, repair step adjusted. I think I'm done here and all known cases should be adressed.
@rullzer would be good if you could have a look. See #25113 (comment) for the repair step summary. Maybe I could add this in the class description.

Next step: the JS part.

@PVince81
Collaborator

Added more unit tests.

Now all that is left is the JS part.

@PVince81
Collaborator
  • TODO: tweak version check for the repair step. Some people might be on 9.1.0RC1 but also need repair
@PVince81
Collaborator

And JS part done.

@owncloud/sharing please review and test.

Please note that I'll have to adjust the version check here https://github.com/owncloud/core/pull/25113/files#diff-638fff1908dfeea3094e9060752f9b0fR305

For the merge on 9.2/master and 9.1.1/stable9.1, it will be "run repair step if coming from OC < 9.1.1".
For the backport on 9.0 it will be "run the repair step if coming from OC < 9.0.4".

@PVince81
Collaborator

A To test the repair step

  1. Setup OC <= 9.0.3
  2. Create shares based on the scenarios from #25113 (comment)
  3. Check that the recipient has duplicated received folders (you might delete some, for testing)
  4. Run upgrade to this branch
  5. Check that the recipient has no more duplicates

B To test creating shares

  1. Setup OC on this branc
  2. Create shares based on the scenarios from #25113 (comment)
  3. Check that the recipient has no duplicate received shares

@owncloud/qa

@SergioBertolinSG SergioBertolinSG modified the milestone: 9.1.1, 9.2 Jul 13, 2016
@SergioBertolinSG
Member
SergioBertolinSG commented Jul 13, 2016 edited

Integration tests are ok and pass ๐Ÿ’š
Testing manually including some reshares the original problem I see it fixed.
Pending upgrade test.

@SergioBertolinSG
Member
SergioBertolinSG commented Jul 14, 2016 edited

After an upgrade from stable9, duplicated folders are still there, not cleaned.
Sharing another folder in the same way didn't create duplicated folders after upgrade.

@PVince81
Collaborator

@SergioBertolinSG this could be because of the version check that doesn't work for all upgrade paths.

Try changing this line #25435 to if (true) {.
Then run maintenance:repair (or the upgrade).

I still need to figure out a good way to run the repair only once. Maybe a flag in oc_appconfig ?

@SergioBertolinSG
Member

What line? it is missing in the link

@rullzer
Contributor
rullzer commented Jul 14, 2016

๐Ÿ‘
Awesome work.

I still like the combinedshare idea. But later I guess.

@SergioBertolinSG
Member
SergioBertolinSG commented Jul 14, 2016 edited

Changing that line and running mainteinance:repair it has worked correctly.
I guess then it just needs to detect that this should be triggered when upgrading.

@PVince81
Collaborator

@SergioBertolinSG I have now adjusted the version check. If you upgrade from stable9 to this branch it should now properly run the repair.

When backporting this to 9.1 and 9.0 we'll need to adjust the versions again.

@SergioBertolinSG
Member

Works ๐Ÿ‘

@PVince81
Collaborator

Rebased for CI

@PVince81
Collaborator

Rebased and adjusted version for 9.2

@PVince81
Collaborator

how many timeswill I need to rebase this ?

rullzer and others added some commits Jun 15, 2016
@rullzer @PVince81 rullzer Group shares with same source and target
Fixes #24575

Note that this is a very limited solution and eventually we want smarter
merging!
aa42b7b
@PVince81 PVince81 Add integration tests for merging received shares e5af146
@PVince81 PVince81 Improved share grouping readability + fixed test c97bb28
@PVince81 PVince81 Add repair step for unmerged shares (WIP) cb683dd
@PVince81 PVince81 Added more tests for sharing's MountProvider fb0f186
@PVince81 PVince81 Group incoming shares for resharing in JS c4db9ad
@PVince81 PVince81 Adjust repair version check for unmerged shares
d0244f5
@PVince81
Collaborator

Close enough for CI => merge

@PVince81 PVince81 merged commit a584840 into master Jul 19, 2016

12 of 16 checks passed

core-ci-linux-swift-primary-storage/database=mysql,label=SLAVE Build #57628 failed in 24 sec
Details
server-master-linux-externals-ci/database=sqlite,external=smb-silvershell,label=SLAVE Build #11863 found unstable in 27 sec
Details
server-master-linux-externals-ci/database=sqlite,external=smb-windows,label=SLAVE Build #11863 found unstable in 10 sec
Details
server-master-linux-externals-ci/database=sqlite,external=swift-ceph,label=SLAVE Build #11863 found unstable in 1 min 19 sec
Details
Scrutinizer 3 new issues, 13 updated code elements
Details
cla-bot-core Build #5391 succeeded in 28 sec
Details
continuous-integration/php-5.4 Build #5995 succeeded in 4 min 46 sec
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
core-ci-linux-jsunit/database=sqlite,label=SLAVE Build #63738 succeeded in 31 sec
Details
core-ci-linux/database=mysql,label=SLAVE Build #32580 succeeded in 10 min
Details
core-ci-linux/database=oci,label=SLAVE Build #32580 succeeded in 29 min
Details
core-ci-linux/database=pgsql,label=SLAVE Build #32580 succeeded in 9 min 22 sec
Details
core-ci-linux/database=sqlite,label=SLAVE Build #32580 succeeded in 3 min 34 sec
Details
ocs-api-integration-tests-ci Build #12317 succeeded in 13 min
Details
server-master-linux-externals-ci/database=sqlite,external=webdav-ownCloud,label=SLAVE Build #11863 succeeded in 6 min 45 sec
Details
server-master-linux-php7-ci/database=sqlite,label=SLAVE Build #40970 succeeded in 2 min 35 sec
Details
@PVince81 PVince81 deleted the group_shares branch Jul 19, 2016
@PVince81 PVince81 modified the milestone: 9.2, 9.1.1 Jul 19, 2016
@PVince81
Collaborator
PVince81 commented Jul 19, 2016 edited

stable9.1: #25534
stable9: #25543

@PVince81
Collaborator

Looks like stable9 backport will be tricky, the old code is using old APIs and an old way. Or might require backporting more stuff.

@PVince81
Collaborator

From what I see a lot of the code would require this commit 6123bad from #23919.

Because on stable9 the MountProvider and SharedStorage still use the old array-style shares instead of the ShareManager style. I'm not sure I want to risk backporting this, so will see if there is a way to make it work with the old code.

@PVince81
Collaborator

stable9 PR #25543

@PVince81
Collaborator

Looks like this fix is not enough, there's another scenario that is not covered: #25564
This is getting tiring...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment