5

We use SFDX with our Managed Package development, and have been for a few months now. All was fine until today where new scratch orgs are messing up sharing.

We have scripting that creates the scratch org with the scratch def JSON including:

"features": [ "ExternalSharing",

We then push our source base to the newly created scratch org. Our custom objects' object-meta.xml files include defaulting the sharing thus:

<externalSharingModel>ReadWrite</externalSharingModel>
<sharingModel>ReadWrite</sharingModel>

It used to be that this would result in entries like the following in the Sharing Settings:

Object | Default Internal Access | Default External Access | Grant Access Using Hierarchies Invoice | Public Read/Write | Public Read/Write | Checked

Today we are finding that the Sharing Settings show:

Invoice | Public Read/Write | Private | Checked

We have some unit tests that rely on running some code as a different user, and this change in behaviour is breaking our tests.

This happens with SFDX CLI 7.8.1 and 7.11.2.

I'm assuming this is some breaking change in the Summer '19 release (the instance on which the scratch org resides is running "Summer '19 Patch 9.5" according to the status dashboard though I don't know when this changed last).

Anyone seen the same problem? Do you have an automated solution?

Improve this question

3 Answers 3

Reset to default
2

It looks like a regression in Summer '19. These is an entry in the Summer '19 release notes related to this. However, this doesn't explain why the explicit definition of external sharing model access on the various objects is being ignored (other than this being a bug).

The only workaround we have found at this point is to push the source to the scratch org, wait while the sharing calculation is performed in the background and only once that is done execute a deploy to re-send the object meta to the scratch org:

sfdx force:source:deploy --sourcepath force-app/main/default/objects -u alias

This forces all the object meta files to be deployed, even though there are no tracked changes. However, an attempt to do this before the initial sharing calculation has finished will not resolve the problem and gets the following error:

The sharing calculation you requested can't be processed right now, because it interferes with another operation already in progress. Please try again later

UPDATE:

We set up scripting to do the force:source:deploy of the object definitions that iterates until it succeeds which worked around the sharing calculation problem. However, once that's done we have to do a further push of everything to get the scratch org tracking, um, back on track. And then we hit further issues because part of that deployment is a permission set we use to ensure our scratch org user has permissions against our custom objects. And this causes the push to fail and the scratch org becomes useless. I can't even figure out how to prevent push of the permission set using the .forceignore file...

I am really looking forward to Salesforce actually fixing this issue - it is wasting so much of our time!

Improve this answer
1

Yes there was a critical update that is the likely cause of this - Enable External Org-Wide Defaults in Orgs with Communities or Portals (Critical Update, Enforced).

Our situation was a little different as described here How to set the externalSharingModel for managed package objects using automation?, so it is not certain that the additional sfdx force:source:deploy solution described there will help. But FYI.

Improve this answer
5
  • thanks for that. I'm not really sure I understand why it is breaking for us. Reading the critical update, it suggests that the external sharing levels are set to match the internal levels and we have set BOTH to ReadWrite. So we shouldn't be seeing external as Private when internal is ReadWrite, right? I also don't understand why it should ignore what we expressly state the sharing levels in the objects.
    – Phil W
    Jun 18, 2019 at 10:56
  • I tried "sfdx force:source:deploy -u thealias -pforce-app/main/default/objects" as a workaround, but this had no impact.
    – Phil W
    Jun 18, 2019 at 10:56
  • Yeah @PhilW We were not setting values for externalSharingModel at all but looks like you are setting them correctly. Was hoping a second pass would fix but sounds like it didn't. FYI the only feature we have on is "features": ["Communities"].
    – Keith C
    Jun 18, 2019 at 11:12
  • releasenotes.docs.salesforce.com/en-us/summer19/release-notes/…
    – Phil W
    Jun 18, 2019 at 13:27
  • No mention of how to automate this for scratch orgs. Very annoying. Will raise on ISV forums.
    – Phil W
    Jun 18, 2019 at 13:27
1

It looks like this is now a Known Issue, attributed to Summer '19, with a fix scheduled for Spring '20. The only provided workaround is manually update sharing access.

Default External Access is overriden in Summer'19 when updating objects via Packages or MDAPI

Improve this answer
1
  • Yes, indeed. Sorry, I forgot to update with this answer.
    – Phil W
    Aug 8, 2019 at 19:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .