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

Add FindAcceptedUsers method to OCM Invite API #1527

Merged
merged 5 commits into from
Mar 11, 2021

Conversation

ishank011
Copy link
Contributor

@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 | [email protected] | Richard Feynman |
+--------------------------------------+-------------+---------------------+-----------------+
>>
>> ocm-find-accepted-users rich
+--------------------------------------+-------------+---------------------+-----------------+
| OPAQUEID                             | IDP         | MAIL                | DISPLAYNAME     |
+--------------------------------------+-------------+---------------------+-----------------+
| 932b4540-8d16-481e-8ef4-588e4b6b151c | example.org | [email protected] | Richard Feynman |
+--------------------------------------+-------------+---------------------+-----------------+
>>
>> ocm-find-accepted-users example
+--------------------------------------+-------------+---------------------+-----------------+
| OPAQUEID                             | IDP         | MAIL                | DISPLAYNAME     |
+--------------------------------------+-------------+---------------------+-----------------+
| 932b4540-8d16-481e-8ef4-588e4b6b151c | example.org | [email protected] | 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 |
+--------------------------------------+-----------------+--------------------------------------+----------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------+-------------------+-------------+--------------------------------------+-------------------------------+-------------------------------+

@ishank011 ishank011 requested a review from labkode as a code owner March 9, 2021 13:17
@ishank011 ishank011 requested a review from mirekys March 9, 2021 13:20
@ishank011 ishank011 force-pushed the find-accepted-users branch 3 times, most recently from 95b0c24 to b0aa78e Compare March 10, 2021 13:39
Copy link
Member

@mirekys mirekys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ishank011 force-pushed the find-accepted-users branch from b0aa78e to 56bca06 Compare March 11, 2021 12:24
@ishank011
Copy link
Contributor Author

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

mirekys commented Mar 11, 2021

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 👍

@labkode labkode merged commit 73f1c7b into cs3org:master Mar 11, 2021
@ishank011 ishank011 deleted the find-accepted-users branch March 14, 2021 20:07
ffurano pushed a commit to ffurano/reva that referenced this pull request Apr 19, 2021
ffurano pushed a commit to ffurano/reva that referenced this pull request Apr 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants