Add FindAcceptedUsers method to OCM Invite API

[ishank011]

@mirekys this is the current workflow. You can search for the user and then send a create share request using the results obtained. These steps will be merged in the UI. Please let me know your thoughts or if there are other workflows we can implement.

Depends on cs3org/cs3apis#111

>> ocm-find-accepted-users
+--------------------------------------+-------------+---------------------+-----------------+
| OPAQUEID                             | IDP         | MAIL                | DISPLAYNAME     |
+--------------------------------------+-------------+---------------------+-----------------+
| 932b4540-8d16-481e-8ef4-588e4b6b151c | example.org | richard@example.org | Richard Feynman |
+--------------------------------------+-------------+---------------------+-----------------+
>>
>> ocm-find-accepted-users rich
+--------------------------------------+-------------+---------------------+-----------------+
| OPAQUEID                             | IDP         | MAIL                | DISPLAYNAME     |
+--------------------------------------+-------------+---------------------+-----------------+
| 932b4540-8d16-481e-8ef4-588e4b6b151c | example.org | richard@example.org | Richard Feynman |
+--------------------------------------+-------------+---------------------+-----------------+
>>
>> ocm-find-accepted-users example
+--------------------------------------+-------------+---------------------+-----------------+
| OPAQUEID                             | IDP         | MAIL                | DISPLAYNAME     |
+--------------------------------------+-------------+---------------------+-----------------+
| 932b4540-8d16-481e-8ef4-588e4b6b151c | example.org | richard@example.org | Richard Feynman |
+--------------------------------------+-------------+---------------------+-----------------+
>>
>> ocm-share-create -grantee 932b4540-8d16-481e-8ef4-588e4b6b151c -idp example.org /home/a.txt
create share done
+--------------------------------------+-----------------+--------------------------------------+----------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------+-------------------+-------------+--------------------------------------+-------------------------------+-------------------------------+
| #                                    | OWNER.IDP       | OWNER.OPAQUEID                       | RESOURCEID                                                                             | PERMISSIONS                                                                                                     | TYPE              | GRANTEE.IDP | GRANTEE.OPAQUEID                     | CREATED                       | UPDATED                       |
+--------------------------------------+-----------------+--------------------------------------+----------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------+-------------------+-------------+--------------------------------------+-------------------------------+-------------------------------+
| 2ea37028-0da5-4657-8ddc-c7e2014fb24b | cernbox.cern.ch | 4c510ada-c86b-4815-8820-42cdf82c3d51 | storage_id:"123e4567-e89b-12d3-a456-426655440000" opaque_id:"fileid-einstein%2Fa.txt"  | permissions:<get_path:true initiate_file_download:true list_container:true list_file_versions:true stat:true >  | GRANTEE_TYPE_USER | example.org | 932b4540-8d16-481e-8ef4-588e4b6b151c | 2021-03-09 14:14:24 +0100 CET | 2021-03-09 14:14:24 +0100 CET |
+--------------------------------------+-----------------+--------------------------------------+----------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------+-------------------+-------------+--------------------------------------+-------------------------------+-------------------------------+

[mirekys]

Thanks @ishank011, I think that this should be enough for what is needed here (atleast for 2)). It wouldn't exactly solve 1) (e-mail used for sending the invitation mail may be completely different from e-mails in accepted users model), but that shouldn't be much of a problem, given that the share originator always knows person's name AND e-mail or idp he used for accepting the invite. Only issue I could think of would be if the originator knows only a person's name and invite e-mail address, there could easily be multiple persons with the same name, even on the same idp, in his accepted users and it may not be easy to determine who is who. Maybe adding some timestamp when the invite token was accepted would help with this?

[ishank011]

@mirekys I don't think the first case can be solved. Email is not the only way in which tokens are forwarded. So searching using that would fail in those cases.

I don't see how timestamps would help. If multiple such users with the same name accept the same token, how would the original user know which one to pick?

[mirekys]

I was thinking that the original user approx. knows when he sent the invite to the person he wants to share something with. Timestamp could help him to eliminate people with the same name, that accepted his invites much earlier, and find the most recent accepted users faster (results could be sorted by that timestamp). It doesn't help much with the case of sending a bunch of invites to same-named people at the same time, but it's another factor that could help with searching through accepted invites.

It's just a suggestion, I'm otherwise ok to go with what is already implemented in the PR 👍