Saltar al contenido principal

Decidir qué registros ve un visitante

Objetivo​

Indicar una sola vez que los registros de una tabla pertenecen al cliente que nombran, para que cada visitante del portal que haya iniciado sesión vea los suyos y los de nadie más, a través de todas las API personalizadas que use su portal y de todas las que alguien agregue después.

El problema que resuelve​

Su portal lee a través de API personalizadas, y un script ya puede preguntar quién llama:

var mine = runQuery({
  entity: 'par_ticket',
  filter: { connector: 'And', conditions: [
    { field: 'par_customer', operator: 'Equals', value: portalCustomerId() }
  ]}
});

Funciona. Funciona desde que los visitantes pueden iniciar sesión. El problema es que hay que escribirlo otra vez en cada script, y cuando falta no se nota: una API sin ese filtro tiene exactamente el mismo aspecto que una API con él, devuelve filas sin ningún problema y le muestra a un cliente los tickets de otro.

Una regla de relación del portal saca esa frase de los scripts y la lleva a la tabla.

Antes de empezar​

  • Su portal está configurado como Personas que inician sesión; consulte Pedir a los visitantes que inicien sesión. Una tabla con una regla de relación no la puede leer un portal que cualquiera puede abrir, porque no habría nadie a quien pertenecieran sus registros.
  • Su tabla tiene un campo que contiene el cliente: lo habitual es una búsqueda a Cuenta, porque eso es la empresa de un visitante.
  • Sus visitantes son miembros de un cliente. Quien se ha registrado y todavía no se ha unido a ninguna empresa no coincide con nada, que es la respuesta segura y probablemente no la que quiere que vea.

Pasos​

  1. Abra su solución y elija Directivas de datos.

  2. Pulse Nuevo y asígnele un nombre: Los tickets pertenecen a su cliente.

  3. Establezca Tipo en De quién son los registros (portal).

  4. Elija la tabla.

  5. Escriba la condición:

    Record.par_customer == Portal.CustomerId

    Es el editor de código de la plataforma, así que un nombre que no conoce, como Portal.CustomrId, se subraya mientras escribe en lugar de rechazarse al guardar.

  6. Deje marcada la casilla En vigor y pulse Guardar.

Esa es toda la funcionalidad. No hay que conceder, referenciar ni activar nada más.

Con qué puede comparar​

Cinco datos sobre el visitante que ha iniciado sesión, y la condición tiene que mencionar al menos uno; si no, no está diciendo de quién son estos registros.

Qué es
Portal.CustomerIdLa empresa a la que pertenece. El que usará casi siempre
Portal.ContactIdSu propio registro de contacto, cuando tiene uno
Portal.UserIdEl propio usuario del portal
Portal.EmailSu dirección de correo electrónico
Portal.Role"Owner", "Billing" o "Member" en su empresa

Puede unir condiciones con && y ||, y comparar también los campos de la propia tabla:

Record.par_customer == Portal.CustomerId && Record.par_status != "Draft"
CurrentUser no es el visitante

En un portal, el «usuario que ha iniciado sesión» es el propio servidor del portal: una única identidad que comparten todos los que lo usan. Por eso una regla de relación no puede leer CurrentUser, y por eso una directiva de datos normal no puede leer Portal. La pantalla rechaza ambas cosas al guardar.

Qué hace exactamente​

  • Todas las lecturas se acotan, sea cual sea la API personalizada que pregunte. Puede quitar el filtro de los scripts que lo tienen, aunque no es obligatorio.
  • Se rechaza una creación que guardaría un registro asociado a otro cliente, comprobando el registro tal como se guardará realmente. También se rechaza una edición que lo trasladaría.
  • Un visitante que no pertenece a ninguna empresa no ve nada; tampoco los registros cuyo cliente está en blanco.
  • Una regla por tabla. Si necesita sustituir una, escriba la nueva con En vigor desmarcado y después intercámbielas.

Lo que no hace​

No hace privada la tabla. Su propio personal, con sesión iniciada en la plataforma, ve lo que su rol de seguridad le permite ver, exactamente igual que antes. La regla trata sobre los visitantes del portal; no sustituye a conceder a un rol acceso a registros.

No se concede a un rol, y la pantalla lo rechazará si lo intenta. Pertenece a la tabla. Esa es la idea: una regla que hay que acordarse de conceder es una regla que se puede olvidar conceder.

Solución de problemas​

«Una regla de relación del portal tiene que indicar qué registros pertenecen al visitante». Su condición nunca menciona Portal. Tal como está escrita, es un filtro normal, que es otra cosa.

«…ya es la regla de relación del portal para…». Una sola regla decide de quién son los registros de una tabla. Desactive la otra, o edítela en lugar de agregar una segunda.

Un visitante no ve nada. Compruebe que es miembro de un cliente y que el campo de su condición es el que realmente contiene el cliente: una condición que compara el campo equivocado no coincide con nada, en lugar de coincidir con todo, deliberadamente.

El portal no se deja guardar con la tabla en su lista. El portal está configurado como Cualquiera. Una tabla cuyos registros pertenecen a un visitante que ha iniciado sesión necesita un portal que tenga visitantes con sesión iniciada.

Temas relacionados​