)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":18816,"name":"Maurice Escher","display_name":"carthaca","email":"maurice.escher@sap.com","username":"mapocace"},"change_message_id":"597857311a514b0dd402b99cdea572fe18ec5eb0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e5b212b4_81077e11","updated":"2026-05-21 08:24:02.000000000","message":"Patch from our fork looks well applied to upstream/master.\nI will not give +2, because I co-authored.\n\nProbably we should upstream the \u0027undelete\u0027 feature, too? Because otherwise this change here is presented a bit out of context.","commit_id":"5bb8db605359f9864094320cf8e183487edd7726"},{"author":{"_account_id":32919,"name":"kiran pawar","display_name":"Kiran Pawar","email":"kinpaa@gmail.com","username":"kpdev"},"change_message_id":"65a98b2823cb0493bff03b3fdab10db8a31f63cb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f9ac6d8e_6402126f","in_reply_to":"e5b212b4_81077e11","updated":"2026-05-21 11:12:40.000000000","message":"ok, upstream support soft-delete and restore feature. We can introduce our downstream extension as \u0027undelete\u0027 share. This will be applicable to certain backends which dont delete the share immediately and keep it in recovery queue e.g. NetApp. \n\nOnce share is deleted from manila, if retention hours have non-zero value the share will go in recovery queue. The undelete share command will read deleted entry from manila db, validate other fields like share network, share server etc. and if all are still valid, pass share instance info to backend driver to check if it still exist in recovery queue, If exist, backend will remove share/volume out of recovery queue and make that share alive in manila again. \n\nHowever this patch stands on its own because the guard is correct regardless — deleted_at alone is not a reliable indicator that a record is permanently gone.","commit_id":"5bb8db605359f9864094320cf8e183487edd7726"}]}