I was trying to clean up the discussion on https://sourceforge.net/p/allura/wiki/FAQ/ and move it into the page proper. I deleted a parent discussion node, and now I cannot delete the children
The way it is implemented is that child's controller created from parent's controller, so when parent post is deleted child post lookup fails. In fact, this affects not only delete, but also reply functionality of the child post.
The obvious fix can be that we remove all the children, when parent is deleted. However I don't sure we want to do that. It kinda makes sense, but maybe not :)
We'll need a task to cleanup posts that already have deleted parent. I don't sure we can't detect them, though.
The second approach is to move handling of reply, delete, etc to the thread controller and always lookup post by full id and not by path from a parent. I guess it will require changes in quite a few places on the UI and test.
What do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another option would be keep the deleted post so its children are not affected. If we soft-delete posts with a flag (or maybe another option on the status field) that would work, and also have the benefit of keeping the data in case it needs to be restored (whether or not we surface an "undo" button)
I think we'd want to avoid the 2nd approach you mentioned, which would have a lot of controller & UI changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought of this too and then forgotten to write it down apparently :)
I'll try this first, then. AFAIR we have deleted property for all artifacts
We still will need to deal somehow with posts that already have parent deleted. By simply deleting them, or maybe creating fake 'deleted' parent post for them, so that reply & delete functionality will work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you make the script have a dry-run option and also an option to run for just one tool? I don't really want to run the whole thing on the millions of posts we have on sf.net :)
Attachments of deleted posts are still accessible - they should not be. Same for the single-post view (the part before "/attachment/" in attachment URLs)
Deleted posts are still visible in the moderation list, not sure if we want that or not? Probably not I'm thinking. ModerationController.index()
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thumbnail view of a deleted post's attached image is still visible. Perhaps you could check & raise a 404 in the _check_security of PostController to catch all those cases?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to do that (only for request.method != 'POST', since we need this controller to work for deleted post when we reply/delete/moderate children).
But that does not work well, because all children's attachments are unreachable in this way, since to get the attachment you need a GET request, which passes through chain of PostControllers for deleted parent(s).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The way it is implemented is that child's controller created from parent's controller, so when parent post is deleted child post lookup fails. In fact, this affects not only delete, but also reply functionality of the child post.
The obvious fix can be that we remove all the children, when parent is deleted. However I don't sure we want to do that. It kinda makes sense, but maybe not :)
We'll need a task to cleanup posts that already have deleted parent. I don't sure we can't detect them, though.
The second approach is to move handling of reply, delete, etc to the thread controller and always lookup post by full id and not by path from a parent. I guess it will require changes in quite a few places on the UI and test.
What do you think?
Another option would be keep the deleted post so its children are not affected. If we soft-delete posts with a flag (or maybe another option on the
status
field) that would work, and also have the benefit of keeping the data in case it needs to be restored (whether or not we surface an "undo" button)I think we'd want to avoid the 2nd approach you mentioned, which would have a lot of controller & UI changes.
I thought of this too and then forgotten to write it down apparently :)
I'll try this first, then. AFAIR we have deleted property for all artifacts
We still will need to deal somehow with posts that already have parent deleted. By simply deleting them, or maybe creating fake 'deleted' parent post for them, so that reply & delete functionality will work.
test
Closed #767
ib/1731
Last edit: Igor Bondarenko 2015-05-25
Can you make the script have a dry-run option and also an option to run for just one tool? I don't really want to run the whole thing on the millions of posts we have on sf.net :)
Attachments of deleted posts are still accessible - they should not be. Same for the single-post view (the part before "/attachment/" in attachment URLs)
Deleted posts are still visible in the moderation list, not sure if we want that or not? Probably not I'm thinking.
ModerationController.index()
Closed #775. Force-pushed
ib/1731
(rebase)You can run script like this:
Last edit: Dave Brondsema 2015-06-02
Thumbnail view of a deleted post's attached image is still visible. Perhaps you could check & raise a 404 in the
_check_security
ofPostController
to catch all those cases?I tried to do that (only for request.method != 'POST', since we need this controller to work for deleted post when we reply/delete/moderate children).
But that does not work well, because all children's attachments are unreachable in this way, since to get the attachment you need a GET request, which passes through chain of
PostController
s for deleted parent(s).Closed #782. Updated
ib/1731