All Space Members should be able to create `internal` links

[tbsbdr]

Description

User Stories

• As a Space member I want to create ~~internal links~~ some link so that I can send a "pointer" to my colleagues who are already member of that space/share.

Value

• collaboration

Acceptance Criteria

• Any Space Member (Viewer, Editor ...) should be able to create internal links

Definition of ready

• [ ] Everybody needs to understand the value written in the user story
• [ ] Acceptance criteria have to be defined
• [ ] All dependencies of the user story need to be identified
• [ ] Feature should be seen from an end user perspective
• [ ] Story has to be estimated
• [ ] Story points need to be less than 20

Definition of done

• Functional requirements
  • [ ] Functionality described in the user story works
  • [ ] Acceptance criteria are fulfilled
• Quality
  • [ ] Code review happened
  • [ ] CI is green (that includes new and existing automated tests)
  • [ ] Critical code received unit tests by the developer
• Non-functional requirements
  • [ ] No sonar cloud issues
• Configuration changes
  • [ ] The next branch of the ocis charts is compatible

[tbsbdr]

@micbar tbh I wonder why it is they way it is currently. is this actually a bug?

[micbar]

This currently works as designed. Links are bound to the "can share permission". If we grant that to the users, everybody can share.

[tbsbdr]

hm, yes.. anything we can provide like we had for the private link would be good.

rephrased the userstory:

• As a Space member I want to create ~~internal links~~ some link so that I can send a "pointer" to my colleagues who are already member of that space/share.

[ScharfViktor]

Space member can send the url of the space, like: https://host.docker.internal:9200/files/spaces/project/s1 if another space member has access -> space should be open

[kobergj]

This currently works as designed.

I'm not entirely sure that is correct. At least the code is aware that private links do not require some permissions. https://github.com/cs3org/reva/blob/edge/internal/http/services/owncloud/ocs/handlers/apps/sharing/shares/public.go#L71

Maybe the fact that it still checks for the ocs share permission in that case is just a bug?

[kobergj]

I'm not entirely sure that is correct. At least the code is aware that private links do not require some permissions. https://github.com/cs3org/reva/blob/edge/internal/http/services/owncloud/ocs/handlers/apps/sharing/shares/public.go#L71

Maybe the fact that it still checks for the ocs share permission in that case is just a bug?

Actually, I'm pretty sure this is a bug. The code states it here: https://github.com/cs3org/reva/blob/edge/internal/grpc/services/publicshareprovider/publicshareprovider.go#L219

[micbar]

@kobergj

"All users should create internal links" That comment is true as far as the user permissions are involved.

But on the resource, they also need the AddGrant permission. In their own personal spaces, they have that permission. But not in project spaces.

[kobergj]

But on the resource, they also need the AddGrant permission. In their own personal spaces, they have that permission. But not in project spaces.

Yes I know. But looking at the code making exceptions for internal links I would rather consider this a bug.

But I'm not fighting over this. If you say this a feature - it is a feature :+1:

[micbar]

Chat in person with @kobergj

Solution: We will adapt the logic.

[micbar]

Fix in progress https://github.com/cs3org/reva/pull/4633/commits/4ec7ca5370097689903c334d6573a705082d1ca7

[micbar]

Rebased my reva PR

[micbar]

@dragonchaser @fschade @rhafer review is now possible.

[micbar]

Brought in via #9708