Files attached to standard objects were not shared

[nvankerk]

I can see in the ContentVersion object that the attachments were pushed over to create new content but they are not shared with the parent. My batch job did generate a couple of errors: "Insert failed. First exception on row 0; first error: INSUFFICIENT_ACCESS_OR_READONLY, Invalid sharing type I: [ShareType]" with detail of "(dca_cnvrt_file)". It worked for the custom objects I have, but not Account, Task, Opportunity and Solution. Have you seen this? I'm not a regular chatter user but did follow the steps in the guide to update the options etc.

[douglascayers]

Hi, thanks for the feedback.

I'm guessing it might be related to either org wide sharing settings and/or the user license type of the attachment owners.

The share type "I" means to grant users who have access to the related record view and or edit access to the file based on their view and or edit access to the related record.

• Could you share what Salesforce edition your org is (profession, enterprise, etc)?
• What org wide sharing options you have for those standard objects?
• Do you have Communities enabled?
• What user license type did the attachment owners have? Were they all community users, platform users, full Salesforce license, or variety of license types?

Thanks!

Doug

On Mar 27, 2017, at 8:54 AM, nvankerk notifications@github.com wrote:

I can see in the ContentVersion object that the attachments were pushed over to create new content but they are not shared with the parent. My batch job did generate a couple of errors: "Insert failed. First exception on row 0; first error: INSUFFICIENT_ACCESS_OR_READONLY, Invalid sharing type I: [ShareType]" with detail of "(dca_cnvrt_file)". It worked for the custom objects I have, but not Account, Task, Opportunity and Solution. Have you seen this? I'm not a regular chatter user but did follow the steps in the guide to update the options etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[nvankerk]

I'm using Enterprise and the OWD are Private for standard objects. No communities and owner of the attachments were all full licenses. I think all of them are owned by me as the admin user.

[nvankerk]

My user has View All Data in the profile so perhaps that was part of it?

[nvankerk]

I ran a couple of test parent Ids using the test interface and those added sharing, but it seems that the ones that ran in the batch did not add any sharing (contentDocumentLink). Does that help troubleshoot? Perhaps there is a different logic path for a full batch run vs just the few record ids. Thanks for your investigations.

[douglascayers]

Thanks for the detailed feedback. So strange indeed. In some of my tests I (the modify all sys admin) create attachments then convert them fine in both testing with specific parent ids or full batch.

The only difference in the logic between the two runs is a filter on Attachment.ParentId when the batch job starts. Other than that, all conversion logic is exactly the same.

One thing to note is that the batch job runs in an "all or nothing" mode. So when not scoped to specific parent id(s) then as many attachments as you indicated in the batch size parameter try to be converted at once. So it's very likely that attachments from different parents tried to be saved at the same time and maybe just one or two bad apples ruined the whole basket, so to say.

I'm curious if you can narrow down to which parent(s) specifically don't convert over. For example, is it isolated to Accounts vs. Contacts vs. Tasks vs. Events etc.

Thanks!

[douglascayers]

Hi @nvankerk,

Wanted to follow up to see if you had identified the offending attachment(s) that were failing to convert? If yes, I'm interested to know what changes you had to make to get them converted - if you were able to.

One suggestion for troubleshooting is to try and set the How should view or edit access to the converted file be granted to users with access to the attachment's parent record? option to Users can only view the file but cannot edit it. Behind the scenes this will use ShareType = 'V' for view-only instead of ShareType = 'I' for inferred view/edit access.

Thanks,

Doug

[nvankerk]

Sorry I have been swamped and not able to reproduce. One consideration is for migrating over Conga Template related attachments - the creation does not seem to keep the same order as the original so the 'last uploaded' file isn't always the same as in the Attachments. Unless I forgot a step? I will test again in May and let you know. Apologies for the delay.