[#CONF-8848] Editing an attachment to removes author and date information from previous versions

Confluence

Editing an attachment to removes author and date information from previous versions

Created: 05/Jul/07 04:08 PM Updated: 15/Jan/08 05:59 PM

Component/s:

Attachments

Affects Version/s:

2.5.4

Fix Version/s:

2.7.1

Time Tracking:

Not Specified

File Attachments:

None

Image Attachments:

1. Attachments with Historical Versions - all names and dates changed.jpg
(175 kB)

Issue Links:

Cloners

This issue is derived from:

~~CONF-7285~~ Moving attachment to another page clobbers authors of previous versions

Reference

This issue relates to:

~~CONF-9265~~ Attachment history gets lost

This issue is related to:

CONF-9946 Wrapping Doesn't Work Properly in Attachments Tab and the Attachment Macros

~~CONF-8863~~ Retain the Original Create Date on Attachments despite Edits to FileName, Comment Type, Content Type, or Page location

Participants:	Andrew Lynch [Atlassian], Andy Schoenbach, Dave Loeng [Atlassian], Emily Fort, Matt Ryall [Atlassian] and Paul Curren [Atlassian]
Since last comment:	32 weeks, 1 day ago
Internal Complexity:	6
Resolution Date:	15/Jan/08 05:59 PM
Internal Value:	6
Labels:

Description

« Hide

When an attachment (that contains several historical versions) is moved to another page, all authors of previous versions are set to the person who moved the attachment.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Andy Schoenbach added a comment - 05/Jul/07 04:21 PM

We are using Confluence 2.5.4 and this problem is still occuring. In fact, it is not just moving an attachment that causes the problem as this issue was originally defined.

We have observed that ANY Edit action (e.g. changing the File Name, making a New comment, moving it to a different page) to an attachment with historical versions resets the names and dates for all the previous attachment versions to new name of the user making the change and the date to the current date.

[ Permlink | « Hide ]

Andy Schoenbach added a comment - 07/Oct/07 09:24 PM

Is there any progress on this issue? It has been months since this serious problem has been reported.

Since this bug impacts data integrity, we were assured by Support that it would fixed as a priority and we were encouraged when the issue was updated months ago to say it would be fixed in version 2.5x . However, release 2.6 is now available and it does not appear in the list of issues addressed. .

(Reminder: as I noted in my original coment, the title of this issue is not reflective of the full extent of the problem - ANY edit to an attachment causes the resetting of all the names and dates.)

Thank you for any status update you can provide.

[ Permlink | « Hide ]

Matt Ryall [Atlassian] added a comment - 07/Oct/07 09:34 PM

Thanks for flagging this, Andy. I've set an appropriate internal priority of this issue, which is indeed a data loss bug.

Unfortunately, I can't guarantee a fix version. We have a number of critical bugs which we're working through at the moment.

[ Permlink | « Hide ]

Andy Schoenbach added a comment - 07/Oct/07 09:42 PM

OK - Thanks.

[ Permlink | « Hide ]

Emily Fort added a comment - 03/Jan/08 02:54 PM

Has there been any progress on this issue? This is a real pain point and frustration source. Any update would be appreciated.

[ Permlink | « Hide ]

Dave Loeng [Atlassian] added a comment - 08/Jan/08 07:14 PM

Emily and all other interested parties,

You will be happy to know that a fix has been implemented for this bug and will be bundled in our next point release (Confluence 2.7.1).

To quickly summarise the changes, all persons uploading a new version of an attachment will be recorded as the creator of the version (previously this was only done for the first version). This prevents the original authorship of the attachment from being overriden by other modifications.

All other modifications such as rename and attachment move will continue to update the last modifier field only.

The attachments page has been updated to make the following much more clearer: creator, last modifier, creation date and last modification date (before this was just "creator" and "date").