cleanup sharing code, next round

[schiessle]

Some tasks for the next round of clean up for the sharing API

• The sharing table distinguish between "file_source"/"file_target" and "item_source"/"item_target". This shouldn't exists. From the share API point of view it should always be a item, for files we store file IDs and paths in the column, other shares store their identifier. This way we can get rid of a lot of if ($item_type === 'file' || $item_type === 'folder') { ... } else { ... } code. The share API should be a general API and shouldn't make such distinctions.
• while creating a share target, the share API shouldn't create a exclude list. Let the generateTarget() method from each backend handle it. E.g. the file backend checks the filesystem directly with file_exists(). Will remove a lot of overhead and complexity
• unused parameters in lib/private/share/helper.php (see FIXME's)
• check the uses of getChildren() at the sharing back-end. For performance reasons files already has a workaround in lib/private/share/share.php calling getParents() instead . Probably the whole logic to detect if the share is part of a already shared collection should be moved to the back-end. Only there we can implement performant solutions for every use case.

[MorrisJobke]

Isn't all of this fixed with share 2.0 - #19331 cc @rullzer

[rullzer]

@MorrisJobke well some of the stuff is still valid. Since right now we don't want to break anything. And the db cleanup can't be done yet since the calendar and contacts still use it.

[MorrisJobke]

@MorrisJobke well some of the stuff is still valid. Since right now we don't want to break anything. And the db cleanup can't be done yet since the calendar and contacts still use it.

Thanks for the update :)

[rullzer]

Lets continue this in #22209

[lock]

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.