Dreadknux Posted May 17, 2023 Posted May 17, 2023 Hi IPS Staff, have a unique issue concerning Copy to Database feature via Pages/CMS. If I use this feature more than once in a row (i.e. I use Copy to Database on a forum topic to post a 'News' database record, then immediately use Copy to Database on a different forum topic to post a different/new 'News' database record), any uploaded images I added to the first story is automatically added to the Upload Files drawer space. These image/s do not have any relevance to the new database record I'm working on, so I click the 'X' to remove the image from the drawer... but what happens then is that it DELETES the image upload entirely from the first database record that was already published. Steps to reproduce: FIRST Article: Go to a forum topic Click Moderation Actions > Copy to Database. Go to Post Editor Edit the Title and Content fields as desired. Upload one or more images to the Images drawer underneath the Content field WYSIWYG. Insert uploaded image/s to content field as desired. Save record, publish as public record. SECOND Article: Go to a new forum topic Click Moderation Actions > Copy to Database. Go to Post Editor Images from previous Post Editor instance are automatically slotted into the Images drawer underneath the Content field WYSIWG. Remove the irrelevant image/s from the drawer by clicking the 'X' on each image. Complete rest of record as desired, Save record, publish as public record. Visit record URL of FIRST article already published (where uploaded Image/s were originally added). Images are deleted, and are displayed as broken images. Check user's "existing attachment" media - uploaded images have been deleted from here as well. This is obviously not desired behaviour - the images uploaded to one article should not be appearing for use in a different one in the first place, but when trying to remove the irrelevant images from the second article it actually ends up deleting already-posted media content, and that adds extra work for users who now have to go back to the first article and re-upload the same images (if they still have them on file). The only way to get around this in a safe manner (i.e. not deleting the first article's image/s) is, on the second article post editor, to simply not use/insert the irrelevant image/s (which automatically inserts the image/s to the bottom of the published record), then go into 'Edit Record' and remove the image insertions that way. Which is not an ideal solution really. Any chance this can be looked into and fixed please?
Solution Jim M Posted May 17, 2023 Solution Posted May 17, 2023 Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release. Dreadknux 1
Dreadknux Posted May 19, 2023 Author Posted May 19, 2023 Thank you @Jim M. I also wanted to add a note about this that I only just learned this morning, too. This issue occurs to all users who have the permissions to Copy to Database, not just the user that posted the specific articles. So for instance, in my steps/examples given above, I was the sole user creating both articles, but then a different user in the same permissions/usergroup as mine tried to Copy to Database a different topic, and found the images I had previously uploaded in their images drawer too. It also seems to build up all images from past Copy to Database-actioned records as well. So if I do not eventually click an 'X' against the images, they will continue to appear and stack alongside other images uploaded to previously Copy-to-Database'd records. Here's a snapshot of my images drawer, when writing Article #3 (using Copy to Database a third time in a row, without clicking 'X' on images uploaded to previous articles): This issue doesn't seem to occur when directly creating a new record/article to the database (even when doing so in-between multiple Copy to Database article creations), only when using Copy to Database to create a record. Hope this helps narrow things down for you guys. SeNioR- 1
Marc Posted June 14, 2023 Posted June 14, 2023 This issue has been resolved in the latest 4.7.11 release. Please upgrade to resolve this, and let us know if you have any further problems.
Dreadknux Posted June 14, 2023 Author Posted June 14, 2023 I was just going to chase on this 😅 Many thanks for following through Marc/IPS Team, I’ll upgrade later tonight and will follow up if I continue to have any issues. Appreciate the support! Marc 1
Recommended Posts