Indirect share info now visible in favorite and other file lists

[PVince81]

Description

When open the share panel of other flat file lists like the favorites,
the collaborators list and link list are now showing the same entries like
in the "All files" list, which includes indirect shares (via) that were
previously missing.

Related Issue

Fixes #3040

Motivation and Context

How Has This Been Tested?

• TEST: favorite list: indirect collaborators appearing
• TEST: favorite list: indirect links appearing
• TEST: shared with other list: indirect collaborators appearing
• TEST: shared with other list: indirect links appearing
• TEST: shared with me list: indirect collaborators appearing => no via possible here
• TEST: shared with me list: indirect links appearing => no via possible here
• acceptance tests

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• TODO: fix remaining issues (see tests section)
• TODO: add acceptance tests

[PVince81]

I had to change the logic a bit to exclude the current folder, because whenever such info was cached it would also show in "via" despite being the same folder.

Share indicators broken:

• tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature:430
• tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature:695
• ...

[PVince81]

really weird. it seems that the simple act of loading the shares tree within the collaborator list is somehow breaking the automatic update of the share indicator

[PVince81]

• ⚠️ share indicators apparently broken already on Phoenix master: in the folder "alice2bob2charlie+link (IUP, OUP, OLP)" only indirect indicators appear. When opening share panel for two of the entries, the direct indicators properly appear: https://github.com/owncloud/phoenix/issues/3160

[PVince81]

ok, I guess the failure is not related to that OC 10 bug.

[PVince81]

I've manually tested the failing case and it looks like the sharedTree always contains the old state.
For example if at first we have collaborators, the indirect icons are shown when entering the folder.
Then if for that folder I remove all collaborators then enter the folder, it still shows the old indicators.

So something is fishy regarding updating the sharesTree from the panel.

[PVince81]

There is no code for explicitly changing sharesTree... So this means the reason it worked so far on master is only because the information was not cached yet, so exploring into the folder would load the information from scratch.

Now in this PR we load it in advance and pre-cache it. So either we need to dynamically adjust it there or remove and reload the matching sharesTree entries. Forcing a reload feels a bit overkill and heavy, but so does updating the sharesTree structure...

[PVince81]

Problem solved: the new loadSharesTree was loading the tree starting with the current path but it should actually start with the parent one. This prevents caching of the current path which causes the side effects described above. With the fix in place, the existing cache invalidation already works fine for making sure the displayed info is up to date.

[PVince81]

Added acceptance tests, rebased.

[PVince81]

test failure reproducible consistently locally: tests/acceptance/features/webUICreateFilesFolders/createFolderEdgeCases.feature:41

the empty message does appear, but it appears too late when the test already stopped waiting :-S

[PVince81]

ah, there's a delay between the time where the progress bar disappears and the empty message appears, and the test relies on this.

[PVince81]

I'll need to fix $_loadingFolder. Apparently some code outside is also relying on the global "loadingFolder" so I can't put the new logic just in AllFilesList. Have to put it on global scope.

[PVince81]

I've fixed the issue by moving the "is sidebar open" condition to the getter by checking if there's a selected file. Not too nice but does the job for now until we rework the progress bars.

[PVince81]

seems I broke other related stuff now :-(

[PVince81]

apparently an additional "s" has creeped in into the new highlightedFile check... fixed now and the test passes locally.