I am working on an instance that has a large set of ContentVersion data uploaded by Customer Portal Users and saved across many ContentWorkspace(s) or Libraries.

We have encountered some issues with the number of ContentWorkspaces growing too large, and have therefore decided to discard this model and instead use FeedItems to insert new ContentVersion data (which doesn't assign it to a library).

However, previously, when a new Portal User is added, they were assigned to a 'Group' which included all the other users in the same Account. I can only assume that inclusion in this Group with an AccountShare record granted access to the existing Library (as there is no other-way to programatically grant library access: Which object stores Content Library-Members list?) - and no explanation of the relationship between Group membership and Library access except sharing?

As these new users are no longer being added to the Group (causes DML-exceptions), is there any other way to grant them access to these libraries or do I need to pull all the files from the libraries and reinsert them as new FeedItems?

I have written a bulk-job to do this - however, I'm hesitant to run it as it will move well over 300gb of files (and thus creating duplicates will be too much space in our org)

Other Possibility: Would it be possible to reference the original ContentVersion as an attachment to a new FeedItem and will it update the ContentVersion and make it available to users whom are not members of it's original library?


I don't quite understand the issue, so I hope this information is helpful:

Groups can be added as a member of a library, and as you indicated, that is likely how portal users received access. I don't quite get why new users aren't being added, but possibly it's due to the way they were being added is no longer working. I'm not too familiar with manager groups for sharing, but depending on your requirements, it may be worth investigating getting that to work.

As far as your last question, yes you can reference the ContentVersion in a library and share it through a FeedItem. You can use the RelatedRecordId field (SOAP API) to share an existing file on a feed, and then whoever has access to the feed, will have access to the file (and feed access is governed by access to the feed's parent entity). You can also due this through connect.

Another option for sharing bypasses feeds, and it would involve inserting a ContentDocumentLink. This happens indirectly when you create a feed post. Similarly, access is governed by the parent entity.

A key difference to know is that permissions on the file differ, depending on if the file is managed by a library or not. If it's in a library, the library controls access beyond viewing of the file. If The file isn't managed by a library (for example, it's uploaded into Salesforce through a feeditem), then it uses a different permission model, where the owner has full permissions, and the file can be shared to others as viewers or collaborators. For library managed files, it can only be shared out of the library as a viewer. I think knowing whether you want the files to remain managed by a library will be important in determine if you reference existing files, or re-create them not managed by files.

You are able to take a non-library managed file and make it library managed, but you can't do the reverse.

Also worth noting, if you don't use "Groups" (for sharing) to manage access to files, you may be able to use ChatterGroups (CollaborationGroups in the SOAP API). For example, have private groups to represent different accounts, and add portal users as members to the group. They will get access to files shared to the group.

  • Thank you for the insight. I am going to attempt the ContentDocumentLink and FeedItem via RelatedRecordId (to see if I can get the files to be visible). The Group addition was causing an exception because of MIXED_DML_EXCEPTION (Creating a Portal/Community User requires an update to a related Contact) record, and so we're calling @future methods to avoid this exception, but the subsequent updates to add a new User to a Group in a trigger (after insert) leads to exception: Cannot call future method from a future method – jordan.baucke Oct 6 '15 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.