Skip to content
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

Merged
merged 14 commits into from
Jul 28, 2021

Conversation

PVince81
Copy link
Member

@PVince81 PVince81 commented Jul 1, 2021

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:

  1. On instance A share a folder "test" with a group "group1" on instance B
  2. On instance B, add a new user "new-user" to the group "group1"
  3. Login as "new-user"
  4. Go to "Pending shares" and accept the received remote share

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

  • list
  • accept
  • reject
  • re-accept => not possible, once rejected it's gone, by design
  • re-reject => not possible, once rejected it's gone, by design

Group remote share

  • list
  • accept
  • reject
  • add user to group => pending share appears for that user
  • re-accept
  • re-reject

@PVince81
Copy link
Member Author

PVince81 commented Jul 1, 2021

  • bug: adjust endpoint target for rejecting share: needs extra "/pending" suffix

@PVince81
Copy link
Member Author

PVince81 commented Jul 1, 2021

  • bug: some mess happening after accepting a group share, it seems the share entries have duplicated in the DB but now for the current user

I wonder if that existing backend part is really reliable or whether it contains yet to be discovered bugs 🤔

@PVince81
Copy link
Member Author

PVince81 commented Jul 1, 2021

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":

+----+--------+------------+--------------------------------+-----------+-----------------+----------+-------------------------+-------+-------------+-----------------------------------------------------+----------------------------------+----------+
| id | parent | share_type | remote                         | remote_id | share_token     | password | name                    | owner | user        | mountpoint                                          | mountpoint_hash                  | accepted |
+----+--------+------------+--------------------------------+-----------+-----------------+----------+-------------------------+-------+-------------+-----------------------------------------------------+----------------------------------+----------+
|  6 |     -1 |          1 | https://vvortex-release.local/ | 32        | 5HRRJLdWNSZzSmE |          | /new-group-share-accept | admin | named-users | {{TemporaryMountPointName#/new-group-share-accept}} | 3bea95b0013a55aa8d1b0fc5bd9198c9 |        0 |
|  7 |     -1 |          1 | https://vvortex-release.local/ | 33        | ynZpKQYrw5jcN9O |          | /new-group-share-reject | admin | named-users | {{TemporaryMountPointName#/new-group-share-reject}} | 3ef4d6505bba0fc9dd07a6877f387731 |        0 |
|  8 |      7 |          1 | https://vvortex-release.local/ | 33        | ynZpKQYrw5jcN9O |          | /new-group-share-reject | admin | evert       | {{TemporaryMountPointName#/new-group-share-reject}} | 3ef4d6505bba0fc9dd07a6877f387731 |        0 |
+----+--------+------------+--------------------------------+-----------+-----------------+----------+-------------------------+-------+-------------+-----------------------------------------------------+----------------------------------+----------+

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. :-/

@PVince81
Copy link
Member Author

PVince81 commented Jul 1, 2021

@PVince81 PVince81 marked this pull request as draft July 1, 2021 15:52
@szaimen szaimen removed their request for review July 1, 2021 16:56
@PVince81 PVince81 force-pushed the enh/23769/accept-decline-fed-sharing-ui branch from 32bc04a to 7d2b91d Compare July 2, 2021 08:06
@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

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)) {
Copy link
Member Author

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

@PVince81 PVince81 force-pushed the enh/23769/accept-decline-fed-sharing-ui branch from 7d2b91d to 2c59f6c Compare July 2, 2021 13:25
@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

fixed postgresql tests by adding more casting for the returned DB values

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • BUG: can't re-accept after rejecting group share once: this is because the share entry returned by the API is actually the sub-share, and this one can't be re-inserted...
    • fix
    • add unit test for this scenario

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • make sure we only fetch a single share when processing the mount => fetchShare is never called when mounting the filesystem for an accepted share, so no scalability issues

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • remove "reject" action for pending group share as it cannot be discarded

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • prevent sidebar to open/load for remote shares as we have no data ? (click the avatar of owner)

@PVince81 PVince81 added 2. developing Work in progress feature: federation and removed 3. to review Waiting for reviews labels Jul 2, 2021
@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • bug: only remove the "reject" action for received group shares not user shares

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

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.

  • check what happens when operating on the group share id whenever a sub-share id already exists... (the UI operates on the sub-share)
    • from the code this will likely fail as it will attempt to reinsert the already existing entry

=> solved now by operating on sub-share when it exists: #27751

@PVince81
Copy link
Member Author

PVince81 commented Jul 2, 2021

  • backport/split the code that adds missing remote group share handling for status icon ? later if relevant
  • split the code that enhances fileactions ? later if relevant

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>
PVince81 and others added 2 commits July 27, 2021 13:04
Signed-off-by: Vincent Petry <vincent@nextcloud.com>

Co-authored-by: Carl Schwan <carl@carlschwan.eu>
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
@PVince81 PVince81 force-pushed the enh/23769/accept-decline-fed-sharing-ui branch from 927782d to 1125832 Compare July 27, 2021 11:34
@PVince81
Copy link
Member Author

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>
@PVince81
Copy link
Member Author

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.

@PVince81
Copy link
Member Author

@artonge can you review again ?

@PVince81 PVince81 dismissed juliushaertl’s stale review July 28, 2021 08:32

a lot has changed since, please re-review

@juliushaertl juliushaertl merged commit a71294e into master Jul 28, 2021
@juliushaertl juliushaertl deleted the enh/23769/accept-decline-fed-sharing-ui branch July 28, 2021 08:38
@PVince81
Copy link
Member Author

thanks a lot everyone! what a journey...

@PVince81
Copy link
Member Author

/backport to stable22

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

Successfully merging this pull request may close these issues.

Cannot accept or decline federated share after dismissing notification
5 participants