Hi Andy,

I can confirm the issue with all last modification dates being modified when attachment properties are changed. I've filed a separate issue for this:

http://jira.atlassian.com/browse/CONF-12321

I've also created an issue for the attachment headings:

http://jira.atlassian.com/browse/CONF-12322

Cheers,
Dave

Hi Dave - Sorry its taken me a while to get back to this as I needed some time to review 2.7.3 in more detail and consider your comments.

We still have two ongoing issues with the implementation.

1. "Creator" Column Heading: We understand your definition that the "creator" is really the version creator, but most (or all) our users consider the "Creator" to be the person who first loaded the attachment. All subsuqent versions we would consider to be modifications to that original document (consistent with how you handle pages where you show "added by" and "edited by"). Therefore, we found the column header "creator" confusing and we were getting lots of questions until we changed the column heading to say "Creator/Modifier".

Note: we believe there is a significant distinction between the creator/modifier of the attachment content itself versus a modifier of the properties relating to that attachment (i.e. the file name, comment, location). In our implementation, when a property is edited we have changed the parenthic to say "(properties modified by ...)" to make it clear the content has not changed.

2. For the new second date column, when you change one of the properties (i.e. file name, comment, location) all the dates for all previous version property changes are are still changing to the current date. I think you would agree that they shouldn't. I can't provide a screen print because we've simply dropped the display of that extra date since it was confusing and of low historic value).

I hope the above explanations make sense. I'll be happy to elaborate further if that would be helpful. Andy

When there is a multiple version attachment, you now show the Creator as the person who created the latest version, rather than the original creator of the file.

Yes, but you can still find the original creator of the file by looking at the creator of the first version. In fact, if you expand the historical versions, the creator column will now show the person who uploaded each new version. We can't see any information loss in this new layout over the old.

The original date should be the date the file was first loaded, and the creator should be the person who initially loaded the file.

This is exactly what we have implemented. For every new file that is uploaded (be it the first version or subsequent versions) the uploader and upload date are stored appropriately as you said. You only need to expand the versions and look at the corresponding creator and creation date values. What we have done is capture the information you require on a per version basis, rather than on a per attachment basis.

Contrary to your note above, the screen only displays the last modifier - the creator is lost. I can understand not wanting to expend real-estate on showing two names but the earlier way of showing the modifier in a parenthetic was much more useful than this.

The last modifier is still displayed in brackets. To see the last modifier, try adding a comment onto an existing attachment.

Hi Dave

We are finally getting ready to upgrade to 2.7.x and so I got a look at how this has been implemented in 2.7.1. I was very surprised at what I saw.

1. When there is a multiple version attachment, you now show the Creator as the person who created the latest version, rather than the original creator of the file. The Create Date is also the date of this latest version. This is not at all what we expected. The original date should be the date the file was first loaded, and the creator should be the person who initially loaded the file.

2. Contrary to your note above, the screen only displays the last modifier - the creator is lost. I can understand not wanting to expend real-estate on showing two names but the earlier way of showing the modifier in a parenthetic was much more useful than this.

Any way we can get you to reconsider this? We will have to do some custom workarounds to show the information people really want.

Best Regards

Reviewed here - https://svn.atlassian.com/privateeye/cru/CR-400/review

No blocking comments.

Hi,

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").

Cheers,
Dave

Our users are forced to save the attachments with another filename and write comments that the "new" file is actually the new version of the old ones with the original name. This would most likely lead to confusion among our users so please we would appreciate if Atlassian can resolve this issue very soon.

Thanks.

Any update on this issue? It's a serious problem for my organization. Any update would be appreciated.

Thanks for the update Andy. We haven't yet resolved this issue but have given it quite a high internal priority. Please watch the issue for later updates.

I think this is essentially the same problem as reported and documented in Conf-8848. Its a very serious bug.

Note - I don't know why its noted here as being intermittent. In our case (Conf 2.5.4), its completely repeatable - every "edit" of an existing attachment's metadata (filename, comment, location) changes the creator and date of all the attachment's versions.