-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Extend pending shares list in frontend to include remote shares #27751
Extend pending shares list in frontend to include remote shares #27751
Conversation
|
I wonder if that existing backend part is really reliable or whether it contains yet to be discovered bugs 🤔 |
it looks like "oc_share_external" for groups works in a similar fashion like "oc_share": for a group share there's a main entry and sub-entries. This is how it looks like after rejecting the group share "new-group-share-reject":
The trouble is that all these entries are returned by the "/pending" endpoint as is, so I now see the "new-group-share-reject" entry twice in the UI. But the accept/reject actions only operate on the share id of the group share entry, the other ones return 404. It seems that this listing endpoint is missing the logic that transforms it to the point of view of the current user. This logic should be in the backend like for regular shares. :-/ |
yup, confirmed, the complex aggregation logic is missing here: https://github.com/nextcloud/server/blob/enh/23769/accept-decline-fed-sharing-ui/apps/files_sharing/lib/External/Manager.php#L644 |
32bc04a
to
7d2b91d
Compare
I've fixed the backend now and extended the unit tests, it was a bit more complicated than expected. I've used the old style queries to save some time. At some point we should move to the query builder. Up next: retesting through the frontend and checking for bugs |
return !in_array($share['id'], $toRemove, true); | ||
}); | ||
|
||
if (!is_null($accepted)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: I had to move this out of the SQL query because when fetching the group share entry is never "accepted" but the sub-entry might be, and we need to have the non-accepted group share present to delete it from the results with the above filter
7d2b91d
to
2c59f6c
Compare
fixed postgresql tests by adding more casting for the returned DB values |
|
|
|
|
|
I've fixed the mess in the backend and now it is possible to work with the sub-share entry when re-accepting or rejecting.
=> solved now by operating on sub-share when it exists: #27751 |
|
And adjust the accept/decline actions to use the right endpoint for remote shares. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Fix pending shares endpoint to consider user-specific sub-entries for group shares whenever a share was accepted or declined. Added unit test for adding remote group shares. Fixed "removeUserShares" to not send a remote request as we never send remote requests for group shares. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
In the list of pending shares, the option for rejecting the share has been removed. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Instead of just returning false, also log the exception to make debugging database issues easier. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
When accepting a group share, a sub-share entry is created which also has a different id. When accepting or rejecting the sub-share, simply update the "accepted" flag instead of trying to re-insert the entry. Adjust getShare to also properly validate group share membership when called on a sub-share id. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Only remove reject share for remote group shares Also fix share indicator to appear for remote group shares as well. Fix pending remote share icon to be the one of a share. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Accepting and declining can now be done repeatedly on both the parent group share and sub-share with the same effects. Added unit tests to cover these cases, and also when the same operation is repeated. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Use query builder with proper matching for finding the group names. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
When declining a remote group share through the dialog that appears when notifications are off, the mount point is now correctly saved when re-accepting. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Signed-off-by: Vincent Petry <vincent@nextcloud.com> Co-authored-by: Carl Schwan <carl@carlschwan.eu>
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
927782d
to
1125832
Compare
resolved conflicts and fixed route problems and missing imports for LoggerInterface it works again. however, while going through the code with @artonge we found some additional issues to fix |
When deleting a user, we should only delete the direct remote user shares or the remote group based subshares. Signed-off-by: Vincent Petry <vincent@nextcloud.com>
I've now fixed user deletion and also added a new method for group deletion, mostly for the sake of tests: f6f2f63 User deletion should now be properly limited to its share type and group subshares, and so is group deletion. Note: I didn't add a hook yet for group deletion as it seems it will be more complicated and I didn't want to dig further in code unrelated to the task at hand. |
@artonge can you review again ? |
a lot has changed since, please re-review
thanks a lot everyone! what a journey... |
/backport to stable22 |
And adjust the accept/decline actions to use the right endpoint for remote shares.
Note: the backend API was already available.
Fixes #23769
Also makes the following scenario work:
In this scenario no notification is generated for the newly added user, and I don't think we want to.
This PR still makes the pending remote share visible in the correct place.
Tests
Single user remote share
Group remote share