Deleting a user breaks personal shares

[wkloucek]

Steps to reproduce

1. share a file with two persons
2. delete one share receiver
3. restart oCIS to clear caches
4. try to edit the personal share of the leftover person / share the file to another person

Expected behaviour

I can edit the personal share / share the file to another person

Actual behaviour

I can no longer see the personal sharing section on that file

Environment general

oCIS-3.1.0-next.2 with Web 7.0.1

Additional information

originally reported in https://github.com/owncloud/enterprise/issues/5828#issuecomment-1614935038

[wkloucek]

@micbar I'm not fully sure if this can be handled on Web UI side only. Maybe the API should not return data about users that are gone in the first place?

[micbar]

We need a severity and prio

[AlexAndBear]

As spoken with @butonic, the share shouldn'be exposed via the api, so transfering this to ocis and closing my pr

[micbar]

as spoken with @butonic he changed his mind 😄

@butonic

[AlexAndBear]

@micbar @butonic
can you guys give me an update :D ?
I can fix the problem in web as well

https://github.com/owncloud/web/pull/9355/files

[butonic]

@2403905 pinged me as well. @micbar had a code change that when a user is not found returnes the user uuid as username and 'user unknown' or 'group unknown' as the display name.

The reason for that was that users might be disabled ... should we then hide the recipient? will it be returned by the user provider? should it have a disabled flag? then we also would need to expose that in the ocs api ...

if there was a problem resolving the recipient for a share ... the user might come back ... so we should not hide it.

If it cannot come back we should have deleted the share. Now end users can at least clean up shares for users that no longer exist ...

Why not hide the user? because it might just be a temporery error ... and currently there is no way in the ocs api to return a list of shares and mark one of the share as: 'temporary error' ... at least clients woult then have a clean way of deciding wether or not to show the share ...

[AlexAndBear]

So there should be no error anymore, or is there a pr I should check working in conjunction with the web?

[butonic]

@micbar Is there a PR?

[micbar]

@tbsbdr @butonic We need to clarify expectations first.

Should the user see "stale" shares to be able to remove them? Or should we filter them out on the server side?

[tbsbdr]

stale shares should not be shown in the frontend; I assess that showing stale shares would be more an information overload rather than a information gain for a regular user. lets keep it simple.

[2403905]

@tbsbdr Should we filter out the list on the backend or the frontend side?

[tbsbdr]

@butonic said "on the backend" so that we dont break oc10. generally: this decision is up to you as I don't see major end-user facing implications. so mainly technical decision i guess. or: from my side no objections against filtering in the backend

[butonic]

we are going to filter on the server side

[2403905]

The reva PR cs3org/reva#4096
This issue also was relevant if we delete the group.

[wkloucek]

@2403905 is this fixed in oCIS 4.0.1?

[rhafer]

fixed in 4.0.1