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

[sharing-ng] Resources shared from inside of the project space is not listed by /v1beta1/me/drive/sharedWithMe endpoint #8027

Closed
SwikritiT opened this issue Dec 20, 2023 · 1 comment · Fixed by #8233
Labels

Comments

@SwikritiT
Copy link
Contributor

Describe the bug

Resources shared from inside of the project space is not listed by /v1beta1/me/drive/sharedWithMe endpoint

Steps to reproduce

  1. Share a folder or file that is inside of a project space to user einstein
  2. List the share received by following the request
curl -X 'GET' \
  'https://localhost:9200/graph/v1beta1/me/drive/sharedWithMe' \
  -H 'accept: application/json' -ueinstein:relativity -vk | jq

Expected behavior

The response should list the resources shared form a project space with a user like it does for the personal space

Actual behavior

Request returns with

{
  "value": null
}

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

 PROXY_ENABLE_BASIC_AUTH=true 
OCIS_INSECURE=true 
OCIS_ASYNC_UPLOADS=true 
IDM_CREATE_DEMO_USERS=true 
OCIS_LOG_LEVEL=debug 
MICRO_REGISTRY=natsjs 
MICRO_REGISTRY_ADDRESS=127.0.0.1:9233

Additional context

Add any other context about the problem here.

@SwikritiT SwikritiT changed the title Resources shared from inside of the project space is not listed by /v1beta1/me/drive/sharedWithMe endpoint [sharing-ng] Resources shared from inside of the project space is not listed by /v1beta1/me/drive/sharedWithMe endpoint Dec 20, 2023
@individual-it
Copy link
Member

See also #6993

rhafer added a commit to rhafer/ocis that referenced this issue Jan 17, 2024
Resources on project space do not have a real owner assigned. A special
of the type USER_TYPE_SPACE_OWNER is returned as the owner. This type of
user can't be looked up via a GetUser request. So we skip that call for
this usertype.

This also fixes the behavior of 'sharedWithMe' for case when the owner
or creator of a share or shared resource can't be looked up in the 'users'
service. Previously cause the complete request to fail with an error message.
So a single share with an unresolvable owner caused 'sharedWithMe' to fail.
Now we log a warning but return all shares. Those where the owner or creator
couldn't be resolved will have the 'displayName' field of the user in the
'remoteItem.shared.owner' or 'remoteItem.shared.sharedBy' property left
empty.

Fixes: owncloud#8215
Fixes: owncloud#8027
rhafer added a commit to rhafer/ocis that referenced this issue Jan 17, 2024
Resources on project space do not have a real owner assigned. A special
of the type USER_TYPE_SPACE_OWNER is returned as the owner. This type of
user can't be looked up via a GetUser request. So we skip that call for
this usertype.

This also fixes the behavior of 'sharedWithMe' for case when the owner
or creator of a share or shared resource can't be looked up in the 'users'
service. Previously cause the complete request to fail with an error message.
So a single share with an unresolvable owner caused 'sharedWithMe' to fail.
Now we log a warning but return all shares. Those where the owner or creator
couldn't be resolved will have the 'displayName' field of the user in the
'remoteItem.shared.owner' or 'remoteItem.shared.sharedBy' property left
empty.

Fixes: owncloud#8215
Fixes: owncloud#8027
rhafer added a commit that referenced this issue Jan 19, 2024
Resources on project space do not have a real owner assigned. A special
of the type USER_TYPE_SPACE_OWNER is returned as the owner. This type of
user can't be looked up via a GetUser request. So we skip that call for
this usertype.

This also fixes the behavior of 'sharedWithMe' for case when the owner
or creator of a share or shared resource can't be looked up in the 'users'
service. Previously cause the complete request to fail with an error message.
So a single share with an unresolvable owner caused 'sharedWithMe' to fail.
Now we log a warning but return all shares. Those where the owner or creator
couldn't be resolved will have the 'displayName' field of the user in the
'remoteItem.shared.owner' or 'remoteItem.shared.sharedBy' property left
empty.

Fixes: #8215
Fixes: #8027
ownclouders pushed a commit that referenced this issue Jan 19, 2024
Resources on project space do not have a real owner assigned. A special
of the type USER_TYPE_SPACE_OWNER is returned as the owner. This type of
user can't be looked up via a GetUser request. So we skip that call for
this usertype.

This also fixes the behavior of 'sharedWithMe' for case when the owner
or creator of a share or shared resource can't be looked up in the 'users'
service. Previously cause the complete request to fail with an error message.
So a single share with an unresolvable owner caused 'sharedWithMe' to fail.
Now we log a warning but return all shares. Those where the owner or creator
couldn't be resolved will have the 'displayName' field of the user in the
'remoteItem.shared.owner' or 'remoteItem.shared.sharedBy' property left
empty.

Fixes: #8215
Fixes: #8027
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants