Custom Metadata Access Issue in Spring '20 in Aura Component

Question

We have an aura component implemented as below.

Component

<aura:component controller ="MyController">
<aura:handler name="init" value="{!this}" action="{!c.doInit}"/>

JS

// in doInit
var action = component.get("c.getCustomMetadata1");

Apex

@AuraEnabled
public static List<MyWrapperClass> getCustomMetadata1() {
    // SOQL to fetch CustomMetadata1__mdt
    // return a list of wrapper class
}


@AuraEnabled
public static List<CustomMetadata2__mdt> getCustomMetadata2() {
    // SOQL to fetch CustomMetadata2
    // return list of CustomMetadata2 
}

This implementation works fine on Winter '20 sandbox but started breaking on Spring '20 preview sandbox specifically on getCustomMetadata2() method.

On Spring '20 preview, even if the component did not refer to this method during its initialization (this method was never referenced on init at all), just having the class name in controller caused the component to fail and not render with an error message as:

$A.getCallback() Invalid definition for null:MyController: Access to entity 'CustomMetadata2__mdt' denied. Entity not readable

This was though intermittent and not for all Users.

---

Upon investigation we found that the issue was caused because of the critical update Require Customize Application Permission for Direct Read Access to Custom Metadata Types (Critical Update).

As the release notes mentions:

This critical update is enforced in the Spring ’20 release

This update was already enforced and thus was causing the issue on the Spring '20 preview sandboxes but is not activated on Winter '20 and thus it works fine there.

So as noted in the release notes, once we assigned the CustomMetadata2__mdt to respective profile, things were working as expected.

However the release notes also says:

This change doesn’t affect accessibility of custom metadata types from Apex or system mode contexts. Custom metadata types retrieved using your custom Apex code continue to work after this update.

But what we observed was that it works if the return type in the method is not of Custom Metadata but any other type (as it is for getCustomMetadata1()). As soon as we have a return type referring the Custom Metadata directly, the component fails to render right away (as we observed for getCustomMetadata2()).

Now we have two versions of this:

1. CustomMetadata1__mdt is not assigned to the Profile, but is still being referred in Apex method but return type is a wrapper class - this works fine
2. CustomMetadata2__mdt is returned directly in second Apex method - this fails and only works if it is assigned for access on Profile

Additionally the Setup --> Schema settings is enabled for metadata access in Apex.

---

Question

We are also reaching out to Support to get more information on this

But in the meantime wanted to see if anyone has observed this specific behavior? I am still wondering why one version will work vs. not the other when release notes specifies it should work in Apex. Does this mean that we cannot have a Custom Metadata in return type without that metadata access assigned on Profile?

Answer 1

This is anticipated behavior - from the release note

This change affects Visualforce pages and Lightning components that directly reference custom metadata types.

You can see a related known issue for a visualforce scenario where the recommended workaround is indeed to use a wrapper class.

I'm on the team that builds custom metadata, I will work with our doc writer to see how we can clarify this.

Specifically to answer your question:

Does this mean that we cannot have a Custom Metadata in return type without that metadata access assigned on Profile?

Yes, the return value of the AuraEnabled method must be a type that the user has access to (or be a custom apex type).

Answer 2

This issue seemed to be intermittent at the time we first observed this and was never reproducible later.

After keeping the case (#25289425) that we had opened with Support for sometime and that neither the Support nor us were able to replicate the issue after a certain period of time, we concluded that there is no requirement to assign the custom metadata on profile as long as that's accessed through Apex class as mentioned in the release notes:

This change doesn’t affect accessibility of custom metadata types from Apex or system mode contexts. Custom metadata types retrieved using your custom Apex code continue to work after this update.

It just seems that this was broken at one point of time because of the fact we observed this and then later possibly resolved with some patch or other which we were never able to identify!