We intermittently see that when we push an upgrade of our package, users in some orgs loose their permission set assignments (a permission set which is in our managed package as well).

It seems to be random. Are there any known issues around this? Has anyone seen this?

Hi,
Seeing a problem this week where the users of our managed package have started seeing an error related to permission access for the LastViewedDate on an object in our managed package.

when users open our editor page in their org, our apex control queries for the underlying customer object records which make up the model for the editor. the custom objects from our managed package. We perform a global apex describe. The LastViewedDate and other such hidden fields have started to be returned by the apex describe calls.

Schema.DescribeSObjectResult objectDescribe = globalSchema.get(objectName).getDescribe();
Map<String,Schema.SObjectField> objectFields = objectDescribe.fields.getMap();

But then when we perform isAccessible check, it returns false. The isAccessible check is required by Salesforce security review.

If you run the global describe from a dev console within the subscriber org, the LastViewedDate field is not returned.

We are seeing this on sandboxes CS105 and CS93, which are on Summer '20 Patch 13. Seems like a bug was introduced in Salesforce. These fields should not be returned by describe or if they are they should be accessible. On other sandboxes on Summer '20 we are not seeing this issue. Patch 12.6 does not seem to have this issue.

I know that adding tabs for these objects solves the issue, but the question is why this problem is showing up now.

Hi,
Thanks in advance for any help and advice. So we are building a data integration using Bulk API v2, but now we have a big concern as to how we can match up the record ID's returned for insert operations to the records which were sent.

https://developer.salesforce.com/docs/atlas.en-us.api_bulk_v2.meta/api_bulk_v2/get_job_successful_results.htm

Usage Notes
The order of records in the response is not guaranteed to match the ordering of records in the original job data.

First, not sure when exactly the order is not guaranteed. If all records insert succesfully, the order does seem to match.

Second, when some records fail, then the order of course does not match, because the failed records are now in the failed results endpoint. 
So lets say you send in for insert:

Test account 1
Test account 2
Test account 3

And account 2 fails. then the success endpoint for bulk api v2 will return Test account 1 and Test account 3. The failure endpoint will return Test account 2. But there is no way to trace them to the original records we were inserting. how does Salesforce expect that to work?

With Bulk API v1 the results were returned in one list which matched up to the order of the records which were sent in, with the last containing both success and failure.

Is it possible to do this?

Hi, we have written a custom DX plugin and are trying to use the injected connection to the scratch org to login and insert some data. We use the access token which is returned by:

this.org.getConnection().getConnectionOptions().accessToken

To authenticate, but get the error:

The following error occurred during deployment: [UnexpectedErrorFault [ApiFault exceptionCode='INVALID_SESSION_ID' exceptionMessage='Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session hash: XXXXXXX This error usually occurs after a session expires or a user logs out. ' extendedErrorDetails='{[0]}' ] ]



But then if I do a: sfdx force:org:open - u <scratch_org_username> , then it works. 

Is there a call I can make in our DX plugin to force this refresh or anything else to make it work, without having consumers manually go and perform an open?

I tried everything in the API which I could see as relevant, like refreshAuth, but it did not hellp.

Thanks in advance!

When we invoke the metadata api in a summer '16 org with v36.0 of the API (or even 35 or 34), we get the following parser error. It seems like in summer '16 backward compatability was effected? The same works in a spring '16 org and with v37 of the api in summer '16 it works as welll.

Has anyone else faced this?

com.sforce.ws.ConnectionException: unable to find end tag at: START_TAG seen ...<default>false</default><controllingFieldValues>... @10:2935

Hi,
Seeing a problem this week where the users of our managed package have started seeing an error related to permission access for the LastViewedDate on an object in our managed package.

when users open our editor page in their org, our apex control queries for the underlying customer object records which make up the model for the editor. the custom objects from our managed package. We perform a global apex describe. The LastViewedDate and other such hidden fields have started to be returned by the apex describe calls.

Schema.DescribeSObjectResult objectDescribe = globalSchema.get(objectName).getDescribe();
Map<String,Schema.SObjectField> objectFields = objectDescribe.fields.getMap();

But then when we perform isAccessible check, it returns false. The isAccessible check is required by Salesforce security review.

If you run the global describe from a dev console within the subscriber org, the LastViewedDate field is not returned.

We are seeing this on sandboxes CS105 and CS93, which are on Summer '20 Patch 13. Seems like a bug was introduced in Salesforce. These fields should not be returned by describe or if they are they should be accessible. On other sandboxes on Summer '20 we are not seeing this issue. Patch 12.6 does not seem to have this issue.

I know that adding tabs for these objects solves the issue, but the question is why this problem is showing up now.

Hi,
Thanks in advance for any help and advice. So we are building a data integration using Bulk API v2, but now we have a big concern as to how we can match up the record ID's returned for insert operations to the records which were sent.

https://developer.salesforce.com/docs/atlas.en-us.api_bulk_v2.meta/api_bulk_v2/get_job_successful_results.htm

Usage Notes
The order of records in the response is not guaranteed to match the ordering of records in the original job data.

First, not sure when exactly the order is not guaranteed. If all records insert succesfully, the order does seem to match.

Second, when some records fail, then the order of course does not match, because the failed records are now in the failed results endpoint. 
So lets say you send in for insert:

Test account 1
Test account 2
Test account 3

And account 2 fails. then the success endpoint for bulk api v2 will return Test account 1 and Test account 3. The failure endpoint will return Test account 2. But there is no way to trace them to the original records we were inserting. how does Salesforce expect that to work?

With Bulk API v1 the results were returned in one list which matched up to the order of the records which were sent in, with the last containing both success and failure.

Is it possible to do this?