Change Details

This change introduces a new file API called: PhabricatorFileTransform#executeTransformExplicit(PhabricatorFile) This new API creates the transform, plus, it creates a PhabricatorTransformedFile, so that the transformed file can easily be related to the original one. Without that API, the transform is just orphan. This new API is now adopted by: - PhabricatorPeopleProfilePictureController So that the original picture (big) is now mentioned from the cropped thumbnail. So, you can now at least "more easily" find the original picture and delete that. - D25475 - the new API is adopted also there, just as refactor. Ref T15407 Ref T15814

Before this change, any image transform is just orphan as default. This change introduces a new file API called: PhabricatorFileTransform#executeTransformExplicit(PhabricatorFile) This new API creates the transform, plus, it creates a PhabricatorTransformedFile, so that the transformed file is related to the original one. In this phase, if the original file is a builtin, we don't persist that relationship, just like before. Just as additional caution. This new API executeTransformExplicit() is adopted by known calls of executeTransform(): - PhabricatorPeopleProfilePictureController So that the original picture (big) is now mentioned from the cropped thumbnail. So, you can now at least "more easily" find the original picture and delete that. - ManiphestTaskCoverImageTransaction (D25475) - just a refactor - PhabricatorProjectEditPictureController - PhameBlogProfilePictureController - PhortuneMerchantPictureController Deletion considerations: Before and after this change, you were able to delete the parent file. It was just a bit tricky to find it out. After this change, the parent file is related to transforms, so the phd daemon will delete them as well as usual for transforms. This is just a preliminary improvement on the deletion workflow reported from T15407. Any other improvement is welcome. WARNING SPECIFIC TO PROFILE IMAGES DELETION: It seems profile images are handled differently, maybe for performance reasons. So, if you delete your file image, you may see 404 errors in the UX, instead of seeing a default image. This is true until the user uploads a new profile image. Ref T15407 Ref T15814

Before this change, any image transform is just orphan as default. This change introduces a new file API called: PhabricatorFileTransform#executeTransformExplicit(PhabricatorFile) This new API creates the transform, plus, it creates a PhabricatorTransformedFile, so that the transformed file can easily be related to the original one. Without that API,is related to the original one. In this phase, if the original file is a builtin, we don't persist that relationship, just like before. the transform is just orphanJust as additional caution. This new API is nowexecuteTransformExplicit() is adopted by: known calls of executeTransform(): - PhabricatorPeopleProfilePictureController So that the original picture (big) is now mentioned from the cropped thumbnail. So, you can now at least "more easily" find the original picture and delete that. - D25475 - the new API is adopted also there,ManiphestTaskCoverImageTransaction (D25475) - just a refactor - PhabricatorProjectEditPictureController - PhameBlogProfilePictureController - PhortuneMerchantPictureController Deletion considerations: Before and after this change, you were able to delete the parent file. It was just a bit tricky to find it out. After this change, the parent file is related to transforms, so the phd daemon will delete them as well as usual for transforms. This is just a preliminary improvement on the deletion workflow reported from T15407. Any other improvement is welcome. WARNING SPECIFIC TO PROFILE IMAGES DELETION: It seems profile images are handled differently, maybe for performance reasons. So, if you delete your file image, you may see 404 errors in the UX, instead of seeing a default image. just as refactorThis is true until the user uploads a new profile image. Ref T15407 Ref T15814