LastModifiedDate on related List - can that reflect the Attachment LastModifiedDate?

[kcarothers]

Subject says it all, but the LastModifiedDate on the related list on the parent page has the date of the attachment conversion -- it would be more helpful if it was the latest version date of the attachment.

[douglascayers]

Hi @kcarothers,

I agree, that would be nice, but I think one or two factors are against us:

1. It's possible that when the ContentDocumentLink shares the new ContentVersion with the original attachment's parent that this causes an update to the date.

2. Henry Liu, Salesforce Product Manager, who I've worked with on the Notes Conversion project, told me that there is a bug with LastModifiedDate (at least in the realm of creating ContentNotes). But since ContentNotes are built on top of ContentVersions then it may be affecting ContentVersions too (my theory).

[douglascayers]

Update.. I think this may be possible to share the record in one step and not create ContentDocumentLink separately by populating ContentVersion.FirstPublishLocationId.

I'll test soon, so hopefully that will resolve issue with LastModifiedDate being set to "now".

[ksswa]

@DouglasCAyers have you been able to determine if your idea above to use FirstPublishLocationId will work? Or is that still pending investigation?

[douglascayers]

Hi @ksswa,

I've looked into it but haven't yet decided if that's the route I want to take. When using the ContentVersion.FirstPublishLocationId we are not able to set the ContentDocumentLink.ShareType or ContentDocumentLink.Visibility to arbitrary values, they are defaulted.

What that means is that I'd need to remove the conversion options that

• Let you specify if converted Attachments should or should not be shared with community users (if you have a community in your org), and
• Let you specify if converted Attachments should grant view only or edit access to other users who have access to the parent entity

Personally, I'm a fan of giving people those options but I'd really like to get your all's thoughts on if anyone actually uses them.

[douglascayers]

I might be able to take a hybrid approach. If the admin chooses those options that align with the default values then I could simply set FirstPublishLocationId and not create the ContentDocumentLink separately, but if they do deviate then create the link separately. I'm still noodling it...

[douglascayers]

Sorry, forgot to answer your other part of the question. Yes, when specifying ContentVersion.FirstPublishLocationId instead of creating ContentDocumentLink records separately then the LastModifiedDate is preserved. So there is the argument about preserving data history.

[douglascayers]

Ok, you've convinced me ;)

In the spirit of preserving data history then I'm going to switch to using FirstPublishLocationId.

Not having the ability to grant users ability to edit the newly converted files is not a loss feature-wise compared to attachments since attachments don't allow people to edit their contents. Today, you have to physically upload a new one and delete the old one. I will err on the side of caution and leave it to the admins and record owners to further grant sharing as needed. And perhaps it can be argued that company wide, such a huge option might not make sense in all cases.

[ksswa]

This is quite literally a life saver for legal departments who store contracts as attachments. Thank you so much for the noodling!

On Aug 2, 2017 8:29 PM, "Doug Ayers" notifications@github.com wrote:

Ok, you've convinced me ;)

In the spirit of preserving data history then I'm going to switch to using FirstPublishLocationId.

Not having the ability to grant users ability to edit the newly converted files is not a loss feature-wise compared to attachments since attachments don't allow people to edit their contents. Today, you have to physically upload a new one and delete the old one. I will err on the side of caution and leave it to the admins and record owners to further grant sharing as needed. And perhaps it can be argued that company wide, such a huge option might not make sense in all cases.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DouglasCAyers/sfdc-convert-attachments-to-chatter-files/issues/26#issuecomment-319842737, or mute the thread https://github.com/notifications/unsubscribe-auth/AKYHBvMq1QFdbbT0APWFuYXcEy8S-v8fks5sUSKWgaJpZM4N0hO- .

[ksswa]

I will send some screenshots, but I converted a few files one parent ID at a time and they retained the original last modified date perfectly!

I then attempted a few batches of 100 and they updated the last modified date to today...so, I tried to revert back to 1 at a time to see if that was the issue, but even at 1 at a time the last modified date is updating today.

So far, I have been testing with PDFs. I will run a few more tests with other file types, but wanted to give some info on my testing in case there are any immediate ideas that come to mind.

[douglascayers]

Are you seeing this behavior after upgrading to latest version 1.2 of the app? I just released it last night.

[ksswa]

I did have the new package. I have been able to isolate success vs non success.

• All non .pdf attachments behave as expected and retain the Last Modified Date.
• All .pdf files use conversion date for Last Modified.

[douglascayers]

That is interesting... are there any commonalities you can identify about which records have PDFs vs. records that don't? For example, are the PDFs on "Accounts" only or something? No other triggers in the org or third-party apps that might be firing looking specifically for PDFs perhaps?

[ksswa]

I have further tested and it is across all objects tested so far and isolated to PDFs. I am going to test next converting my legacy PDF's to images as this would be sufficient for our org for legacy documents, but wanted to let you know of the one remaining issue that could cause legal department heartburn that I have seen in this fabulous package.

[douglascayers]

Thanks for the follow up and details, really appreciate it!

I'll check out PDFs on my side to see if get same issue. Any info you can share about how your PDFs were generated? For example, did they all come via some program that generated them like special Legal software? Or were they any PDFs people sent in? I'm wondering what further commonality might be there if others don't have same problem.

Thanks!

[vanelus]

@DouglasCAyers, To begin , Thanks for your tool that helped us to achieve the migration of notes &files successfully. We used the version 1.1 of the tool for migration. However, sales users noticed after we have opened the new relatedlist files&notes, that the lastmodifieddate field value was not correct as described here.

Is there a simple manner to correct this date without, redo all the migration process with the version 1.2 of the tool ? Can we do an update on files/notes to correct that?

Thanks in advance for your return. Vanel

[douglascayers]

Hi @vanelus,

You’re very welcome! Unfortunately, we cannot change the LastModifiedDate to earlier value once record exists. You would need to reperform the migration using the latest version of the app.

Doug

[vanelus]

Hello @DouglasCAyers,,

Thanks for your answer. Salesforce Support told me the same thing (we cannot change audit fields when updating records)

Vanel