MyBB Community Forums

Full Version: Malfunction in Drafts for threads with deleted posts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Tested on version 1.8.20.

Example for reproducing:
1) Thread created + replies.
2) First/initial post marked as deleted (Thread diasapperas for members/guests; still apperas for Administrators and is enabled to reply).
3) Create a reply and save as draft.

In User-CP this draft is visible, but there is
- no thread tied to this draft. The template variable remains empty.
- no working URL to edit the draft. The PID of the thread is missing.
- no working form function to delete this draft.

Other drafts will be displayed correctly but there is a strange behaviour with deleting using the checkbox and form element.
Once the deleted post is recovered, the form elements and URLs are working fine again.


Suggested Resolution:

1: Forbid to create a draft for a thread with initial post deleted (so invisible thread) at all - including Admin/Mod.
This is no desirable solution because the deleted post could be recoverd and the thread re-enabled.
Furthermore an Administrator should not be a subject for any restrictions!

2 (preferred): PHP code corrections for generating the URL for Editing and the form element for deleting.
Set the PID correctly with no care of a thread/posts marked as deleted.

[ExiTuS]
Can you test this using the 1.8.21 pre-release packages? I think this may be solved by a different PR introduced.
Noting that this is still an issue in 1.8.26.

Users with drafts saved for threads they no longer have permission to reply to (e.g. thread has been deleted or archived into a forum with no reply permissions) are no longer accessible, presumably because the "edit draft" page is the same as the "post reply" page, which the user no longer has permission to access for that forum/thread.

My ideal solution would be for drafts to be saved in a space independent of thread permissions, so the user can still retrieve drafts regardless of thread status, but I don't know how practical that is.

Issue is also noted here.