Opciones de protección y privacidad para tipos de metadatos personalizados

Paquetes

Para datos confidenciales, como secretos de aplicación, es importante que los tipos de metadatos personalizados se incluyan en un paquete gestionado. Cuando se incluyen en un paquete gestionado y se establecen como protegido o protegido por paquete, no son visibles para organizaciones suscriptoras, lo que facilita convertirlos en una buena ubicación para almacenar ciertos tipos de secretos.

Nota

Los tipos de metadatos personalizados protegidos en un paquete no gestionado se comportan como tipos de metadatos personalizados públicos. Asegúrese de que los secretos, la información de identificación personal o cualquier dato privado están almacenados en tipos de metadatos personalizados protegidos instalados como parte de un paquete gestionado.

Visibilidad

Puede crear tipos de metadatos personalizados protegidos en organizaciones de desarrollador y borrador. Estas opciones para tipos de metadatos personalizados están disponibles.

• Protegido por paquete: Cuando están en un paquete gestionado de segunda generación, solo el código de Apex en el mismo paquete gestionado puede ver el tipo. El nombre del tipo y el registro son visibles si se hace referencia a ellos en una fórmula.
• Protegido: Cuando están en un paquete gestionado, solo el código de Apex en el mismo espacio de nombres puede ver el tipo. El nombre del tipo y el registro son visibles si se hace referencia a ellos en una fórmula.
• Pública: Con independencia del tipo de paquete (gestionado o no gestionado), estos tienen acceso.
  • Apex
  • Fórmulas
  • Flujos
  • API para usuarios con permiso Personalizar aplicación o permisos otorgados a través de perfiles o conjuntos de permisos. El tipo de metadatos personalizado, los campos y los registros no protegidos son visibles en Configuración.

Configuración de esquema

La opción Configuración de esquema, Restringir el acceso a tipos de metadatos personalizados es una preferencia de toda la organización que limita el acceso a tipos de metadatos personalizados. Esta preferencia está activada de forma predeterminada y el acceso de lectura de API a tipos de metadatos personalizados debe otorgarse de forma explícita. Los administradores con el permiso Personalizar aplicación pueden otorgar acceso a los usuarios a través de perfiles y conjuntos de permisos.

Comportamiento de Apex, Visualforce y Aura

Existen diferentes modos de código de ejecución en Salesforce que afectan a la accesibilidad de tipos de metadatos personalizados.

El código Apex que se ejecuta en el modo del sistema ignora los permisos de usuario y su código Apex tiene acceso a todos los objetos y campos. Los permisos de objeto, la seguridad a nivel de campo y las reglas de colaboración no se aplican para el usuario actual. La ejecución en modo del sistema garantiza que el código no falle debido a campos u objetos ocultos para un usuario.

En modo de usuario, funciones como Componentes de Visualforce, Plantillas de correo electrónico de Visualforce y Aura, se ejecuta con respecto a los permisos del usuario y la colaboración de registros.

Nota Las funciones que se ejecutan en modo del sistema, como Apex, no se ven afectadas por la preferencia de organización Restringir el acceso a tipos de metadatos personalizados. Del mismo modo, el modificador de with sharing en la clase Apex no afecta al comportamiento de la consulta como, por ejemplo, isAccessible() y isCreatable(). Si un valor de campo se recupera en Apex y se asigna a una variable no de sObject, el comportamiento es el mismo independientemente de que la preferencia está activada.

Cuando se ejecuta la función en modo de usuario, como Componentes de Visualforce, plantillas de correo electrónico de Visualforce y Aura, debe tener permiso para acceder a los tipos de metadatos personalizados. Por ejemplo, sin permiso, los campos en páginas de Visualforce a los que no tiene acceso no se muestran. La variable global $Setup (disponible en Visualforce y fórmulas) continúa cargando valores por referencia directa (lo que significa, los datos asignados a un tipo de sObject) independientemente del usuario que ejecuta.

Piense en este escenario:

• (1) Apex carga un registro que es una fila incluida en una variable como MyCMT__c.
• (2) Visualforce muestra MyCMT__c.MyPath__c.
• (3) Las comprobaciones de acceso se ejecutan cuando se carga la página.
• (4) No obstante, las comprobaciones no se ejecutan en modo del sistema, que es el comportamiento estándar de Visualforce. Los usuarios sin permiso en el tipo de metadatos personalizado no pueden mostrar la página de Visualforce porque Visualforce reinicia la comprobación de acceso.

class DataHolder{
public string path {get;set;}
public boolean active {get;set;}
}

Este es un ejemplo que incluye la anotación @AuraEnabled para un controlador de componentes Lightning o Aura.

class with sharing MyController {
    @AuraEnabled
    public static List<My__mdt> thisWillNotWork() {
         return [select developername from my__mdt];
    }
    @AuraEnabled
    public static List<String> thisWill() {
        List<String> retVal = new List<String>();
        for(My__mdt config: [select developername from my__mdt]) {
            retVal.add(config.DeveloperName);
        }
        return retVal;
    }
}

Recuperación de la información de tipos de metadatos personalizados

Cuando recupera registros de tipos de metadatos personalizados o un recuento de tipos de metadatos personalizados, el número devuelto por SOQL, Apex, fórmulas, flujos o API puede diferir del número en la interfaz de usuario. Esta diferencia es debido a la configuración de la visibilidad del tipo de metadatos personalizados y el acceso que un usuario tiene al tipo basado en perfiles y permisos.