function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Steve McConnellSteve McConnell 

readMetadata() generates INSUFFICIENT_ACCESS fault for Database.com

In order to succesfully create new objects and fields and configure their visibility, we use the Metadata API's synchronous CRUD operations, which were added in API 30 and API 31.

This works successfully for Salesforce.com instances, but does not behave as expected for Database.com instances; we are seeing the following SOAP fault when attempting to call readMetadata():
INSUFFICIENT_ACCESS: insufficient access rights on cross-reference id

This is impacting our ability to manage our objects and fields via the API, which is necessary for our testing / QA to programmatically perform their tasks.


From the API documentation, the synchronous metadata operations require the "Modify All Data" permission.  For the Salesforce.com instances, this is present for the primary user (which uses the "System Administrator" profile) and everything works as expected.

For the Database.com instances, the user (which uses the "Database.com Admin User" profile) does not have the "Modify All Data" permission.  However, the createMetadata() and deleteMetadata() calls work anyway.

It seems that Database.com uses some custom logic to allow access for certain metadata operations, without having the "Modify All Data" permission.  This was probably in place with the original asynchronous calls:  create(), update(), delete().  I suspect this custom logic was applied when the synchronous versions were added as createMetadata(), updateMetadata(), and deleteMetadata(); that would explain why they continue to work as expected for Database.com.

If this is the case, the solution is for Database.com servers to enable access with the other synchronous CRUD-based metadata calls just like what has been done for the above methods.  The list of other calls is:
readMetadata()
upsertMetadata()
renameMetadata().

If the above guesses are not correct:  how should we address this issue?



For reference, here is the SOAP request body (header trimmed) that was sent to a Database.com server:
<soap:Body>
        <readMetadata xmlns="http://soap.sforce.com/2006/04/metadata">
            <type>Profile</type>
            <fullNames>SolutionManager</fullNames>
            <fullNames>Admin</fullNames>
            <fullNames>MarketingProfile</fullNames>
            <fullNames>ContractManager</fullNames>
            <fullNames>ReadOnly</fullNames>
            <fullNames>Database%2Ecom User</fullNames>
            <fullNames>Database%2Ecom Admin User</fullNames>
            <fullNames>Standard</fullNames>
        </readMetadata>
    </soap:Body>



Here is the full SOAP response to the above request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sf="http://soap.sforce.com/2006/04/metadata">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>sf:INSUFFICIENT_ACCESS</faultcode>
            <faultstring>INSUFFICIENT_ACCESS: insufficient access rights on cross-reference id</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>