Shares are not deleted when user is deleted #1258
Assignees
Labels
Category:Defect
Existing functionality is not working as expected
Interaction:Needs-help
Asking some hints to engineering when the issue can't be reproduced
QA:team
Comments
|
The error I encountered on ocis-server for the above scenario is: |
individual-it
changed the title
|
The issue seems to be that when the user is deleted (in the case of the acceptance tests) from LDAP the shares are not deleted from different issue but same reason:
Response: content of how show ocis know that a user is deleted and recreated in LDAP? For the tests its not enough to delete the json file, the redis server & the ocis-reva services have to be restarted as well |
|
I've raised https://github.com/owncloud/ocis-reva/issues/357 for the clean approach, proper deletion of shares upon user deletion. So far it feels like it won't be a quick and easy task. Another workaround would be to delete shares.json, but that usually requires restarting ocis which we cannot do from the tests. @butonic ideas ? |
|
the workaround could be done by something similar to the testing app in oc10 here the issue for that #130 |
|
And creating a new user that has the same "username" as one in the past does happen in real life - e.g. the staff member gets re-hired, the contractor comes back, the account was being deleted because somehow it was "messed up" and the admin creates it again a few minutes later. We do not want stale metadata (or actual files) of the previous incarnation of the user to suddenly reappear. |
|
From what I see in the code the share.json files are read only once during initialization. I was thinking that maybe we could either have some periodic reload or checking if the file on disk still has the same mtime as before (or if it still exists), if not, reload before performing an operation. This would make it possible to delete/truncate the file concurrently. And even update it... |
|
Detecting changes to the file (with https://github.com/fsnotify/fsnotify) and then recreating it would be a nice workaround, as discussed with @butonic It feels like it's not enough yet as we also need to cleanup the matching values in redis. |
|
POC here for the recreation of shares.json after deletion by the share manager: cs3org/reva#952 |
|
from what I see the Redis code is in the OC storage, so this means the OC storage would also need to know that the user was deleted... or need some kind of trigger to clear its keys... maybe for now we could clear the redis stuff at the end of every test ? |
individual-it
changed the title
refs
added
Category:Defect
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
|
Issue #1226 looks to be the same thing. |
|
@jasson99 I think that this has been fixed. Do you know if it is still a problem? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
|
assigned QA-team to double check if this is fixed, please close if its fixed |
|
The issue has been fixed so closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BrianandCarolCarolcreates folderCarol-folder3Carolshares folderCarol-folder3with userBrianwith permissionsallCarolgets the information about the share created by him asDelete users
CarolandBrianCreate user
AliceandBrianUser
Alicecreates filetextfile3.txtUser
Aliceshares filetextfile3.txtwith userBrianWhen user
Briangets the information about the share shared with him as:Note: Here, when steps 6 to 9 are carried out first, without performing steps 1 to 5, then the response is as:
The text was updated successfully, but these errors were encountered: