[SPO] Add configurable drive item permissions support - #1259
Conversation
This reverts commit 6c86b16.
seanstory
left a comment
There was a problem hiding this comment.
LGTM. Have you shared the results of this branch yet with Gustavo? May be good to get confirmation of output before declaring victory.
| "type": "bool", | ||
| "value": False, | ||
| }, | ||
| "fetch_drive_item_permissions": { |
There was a problem hiding this comment.
will need a corresponding kibana PR, and a corresponding docs PR. Also, CC @artem-shelkovnikov who is working on SPO ftest
There was a problem hiding this comment.
Added RFC to functional test connector.json with 0719134
There was a problem hiding this comment.
Just merged the PR, you can update tests/sources/fixtures/sharepoint_online/connector.json to include the field now
There was a problem hiding this comment.
Also added, but I've to decrement the order also here :)
| "display": "toggle", | ||
| "label": "Fetch drive item permissions", | ||
| "order": 9, | ||
| "tooltip": "Enable this option to fetch drive item specific permissions. Note that this setting can potentially increase sync time.", |
There was a problem hiding this comment.
@leemthompo for review of copy (easier to do this now then have to come back and reword later)
There was a problem hiding this comment.
I think the order needs to be decremented after #1255 (review) - it removes item no. 8
| "identity": { | ||
| "email": prefixed_mail, | ||
| "username": prefixed_username, | ||
| "user_id": prefixed_user_id, |
| prefixed_mail = _prefix_email(email) | ||
| prefixed_username = _prefix_user(username) | ||
| prefixed_user_id = _prefix_user_id(user.get("id")) | ||
| id_ = email if email else username |
There was a problem hiding this comment.
Wondering can we use the user.get("id") here, instead of email/username?
There was a problem hiding this comment.
As we may want to have cross-system identities in the near future, it's probably better to use the email as the id as this is searchable.
There was a problem hiding this comment.
++. The sharepointID isn't typically easy for a customer to look up or reason about. But everyone knows their email address. This is why we decided to use email as the key (ES _id) for SPO.
| "order": 9, | ||
| "tooltip": "Enable this option to fetch drive item specific permissions. Note that this setting can potentially increase sync time.", | ||
| "type": "bool", | ||
| "value": True, |
There was a problem hiding this comment.
This is expected to be True by default, and I don't see 8.9 label in the PR, is migration needed if customers upgrade from 8.9 to 8.10?
There was a problem hiding this comment.
Yes, I would expect that we need one.
There was a problem hiding this comment.
Good call, Chenhui. Tim, can you create and link an issue so we don't forget?
There was a problem hiding this comment.
Created it last week: https://github.com/elastic/enterprise-search-team/issues/5181
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
| @@ -606,9 +606,14 @@ async def drive_items(self, drive_id, url=None): | |||
| yield page | |||
|
|
|||
| async def drive_item_permissions(self, drive_id, item_id): | |||
There was a problem hiding this comment.
So there's no way to fetch permissions in batch?
Do you think doing request batching could help here?
There was a problem hiding this comment.
Just for my understanding: We would pile up to 20 drive items in memory and then fetch the permissions for these 20 at once?
There was a problem hiding this comment.
Yup. Code will get ugly, but that's potentially 20x performance bump?
There was a problem hiding this comment.
Let's do it, if it improves performance 🚀
Co-authored-by: Artem Shelkovnikov <lavatroublebubble@gmail.com>
Co-authored-by: Chenhui Wang <54903978+wangch079@users.noreply.github.com>
| async for site_drive in self.site_drives(site): | ||
| yield self._decorate_with_access_control( | ||
| site_drive, access_control | ||
| site_drive, site_access_control |
There was a problem hiding this comment.
Can drives not be given more granular access than their parent site?
There was a problem hiding this comment.
They're treated as lists AFAIU and they can have unique permissions. Will be addressed in a separate PR 👍 Issue for tracking: https://github.com/elastic/enterprise-search-team/issues/5363
Co-authored-by: Sean Story <sean.j.story@gmail.com>
…issions' into tim/configurable-drive-item-permissions
💔 Failed to create backport PR(s)The backport operation could not be completed due to the following error: The backport PRs will be merged automatically after passing CI. To backport manually run: |
(cherry picked from commit 4060efe)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
Closes https://github.com/elastic/enterprise-search-team/issues/5164
This PR adds a RFC
fetch_drive_item_permissions, which specifies whether drive item specific permissions should be fetched or not. Fetching drive item permissions is now also done via scrolling and not via fetching everything at once.Using the
$batchAPI to batch 20 permission requests for drive items into 1 reducing the number of requests drastically.Note: We add
siteUserandsiteGroupfor drive item permissions, but we don't fetch them during an access control sync yet. This will be part of another PR and will also be made configurable + the dependency checks will be added on the RFC side.A separate PR adding the
fetch_drive_item_permissionsRFC will follow for Kibana.Checklists
Pre-Review Checklist
v7.13.2,v7.14.0,v8.0.0)