Reassign attachments on page delete #1767

New Issue

OVERLORD · 2026-02-05T01:49:08+03:00

OVERLORD commented

2026-02-05 01:49:08 +03:00

Originally created by @jamkuong on GitHub (Jun 15, 2020).

Describe the bug
When I copy a page with the link of attachments, the page is created and the link are okay. However if I delete the original page and the links in the page I've copied are all broken.

Steps To Reproduce
Steps to reproduce the behavior:

Create a new page
Upload an attachment
Copy the link and paste it in the wyswyg editor
Save
Press copy and select a location to save
delete the original page with attachment uploaded
The link in the copied page are broken now

Expected behavior
I expected the links are still possible to download, which means the linkage between pages and attachments should not be so strong.

Screenshots
N/A

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): 0.29.3
PHP Version: N/A
Hosting Method (Nginx/Apache/Docker): N/A

Additional context
Just another suggestion not related to this issue, I think the record handling method may need to improve, since I found that the delete button will fully delete the record in the database and the record deleted is impossible to be recover from anywhere.

I suggest that those delete record should change it's value in status field such as => "status='deleted'".

Originally created by @jamkuong on GitHub (Jun 15, 2020). **Describe the bug** When I copy a page with the link of attachments, the page is created and the link are okay. However if I delete the original page and the links in the page I've copied are all broken. **Steps To Reproduce** Steps to reproduce the behavior: 1. Create a new page 2. Upload an attachment 3. Copy the link and paste it in the wyswyg editor 4. Save 5. Press copy and select a location to save 6. delete the original page with attachment uploaded 7. The link in the copied page are broken now **Expected behavior** I expected the links are still possible to download, which means the linkage between pages and attachments should not be so strong. **Screenshots** N/A **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): 0.29.3 - PHP Version: N/A - Hosting Method (Nginx/Apache/Docker): N/A **Additional context** Just another suggestion not related to this issue, I think the record handling method may need to improve, since I found that the delete button will fully delete the record in the database and the record deleted is impossible to be recover from anywhere. I suggest that those delete record should change it's value in status field such as => "status='deleted'".

OVERLORD added the 🔨 Feature Request label 2026-02-05 01:49:08 +03:00

OVERLORD commented

2026-02-05 01:49:09 +03:00

@ssddanbrown commented on GitHub (Jun 21, 2020):

Hi @jamkuong,

This is the expected behaviour, since attachments are very much related to the original page they're uploaded to, hence why you need to be on the page-edit view to upload. I don't really want to change this if possible, as it keeps the attachment model simple and the permission model sane.

I can see how it may be easy to not think about attachments, when deleting a page, though.
Maybe instead, on the confirm-page-delete screen, we should indicate that there are existing attachments and offer the chance to re-assign them to another page? Would that suit?

@ssddanbrown commented on GitHub (Jun 21, 2020): Hi @jamkuong, This is the expected behaviour, since attachments are very much related to the original page they're uploaded to, hence why you need to be on the page-edit view to upload. I don't really want to change this if possible, as it keeps the attachment model simple and the permission model sane. I can see how it may be easy to not think about attachments, when deleting a page, though. Maybe instead, on the confirm-page-delete screen, we should indicate that there are existing attachments and offer the chance to re-assign them to another page? Would that suit?

OVERLORD commented

2026-02-05 01:49:12 +03:00

@jamkuong commented on GitHub (Jun 22, 2020):

@ssddanbrown I think the re-assign would help in my case. Thanks for your reply =).

@jamkuong commented on GitHub (Jun 22, 2020): @ssddanbrown I think the re-assign would help in my case. Thanks for your reply =).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1767