0

It looks like customer community users can't create Account records because there is no create option in object settings for a customer community profile.

I thought that I could get around this if the page controller was using without sharing. My client side code is accessing salesforce via remote action methods which are in a global without sharing class. My understanding was that the class would run in system mode which would mean that it would ignore user permissions and any object could be queried or inserted.

However, I am getting an OP_WITH_INVALID_USER_TYPE_EXCEPTION when trying to insert Account records when the user is a customer community user despite the fact that as I have said the class is without sharing.

Is my understanding of without sharing wrong? Are the profile CRUD permissions still enforced even in without sharing mode?

Is there any way around this? In other words, how can I insert an Account record when the current user is a customer community user?

Edit

I think I was assuming that without sharing would allow the currently running user to get around CRUD permissions. But it only affects the actual sharing of objects. So, because the customer community users don't have the create permission for the Account object, they will never be able to create one.

Thanks

0

A work around I have used before is to create a copy of the account fields you are interested in syncing on a new custom object (.e.g Account_Shadow__c) to which you can give your community profiles access to CRUD. Then create a trigger to sync the new shadow object to a matching record in the actual Account table. As long as you can hold a reference between the shadow copy and the master account then you should be able to get updates/inserts working easily.

  • Hi Richard. Thanks I like the idea, but unfortunately it's the Account creation that is the issue, not updating the Account. So there will be no existing Account record to synch the Account_Shadow__c to and any trigger will still be run using the existing users CRUD permissions, so we wouldn't be able to create an Account object on insert of an Account_Shadow__c. – Joe Apr 30 '15 at 12:37
  • In that case, when the shadow is created just create an Account. The user permissions don't apply in the trigger context and your users can create accounts. I have this working in a Sites implementation as well as a communities portal. – Richard Durrant Apr 30 '15 at 14:46
  • The currently running user's CRUD permissions still apply in a trigger, though Richard. Users with standard Customer Community licenses don't have create permission for the account object, so they won't be able to create the Account object in the Account_Shadow__c trigger (I did try it just in case :( ) Customer Community Plus and Portal Community users do have create permission for the Account object, so it will work for them. – Joe Apr 30 '15 at 16:17
  • The thing is that the current users' CRUD permissions DON'T apply in a trigger. The trigger runs in system mode and so has access to all objects and fields. See salesforce.com/us/developer/docs/apexcode/Content/… which states this. Perhaps it is an issue with licence types but it is definitely not to do with CRUD. – Richard Durrant May 4 '15 at 10:27
  • 1
    Hi Richard. The trigger does run in system mode and has sharing access to any records, but CRUD permissions (which are the object level access and different to the sharing access which the with and without sharing keywords affects) are still enforced. This IS about CRUD permissions. The customer community user licenses give the user read and edit permissions for the Account object and running in system mode allows any record to be read and edited because every object is shared with them, but they don't have the create CRUD permission, so they can't insert an Account. – Joe May 4 '15 at 10:37

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.