Security Filters (Appsheet Core)

AppSheet AppSheet Q&A
1

Good afternoon community, I make this query, surely it will also help someone. For me it is uncharted territory. Table security filters.

Although I manage with Slices, what I want is to limit access to the formulas panel to users to prevent the app from breaking.

I saw that there is a part in “tables” called security. When I open that I get Security filter (Appsheet Core).
The question is, how is this? since another security associated with the table appears above (Updates, Adds, Deletes, Read Only)

Is it the same security? How does this change, could someone explain to me that I don’t have the slightest idea?

Thank you!

2

The “another security” is what’s called the CRUD permissions (Create, Read, Update, Delete). In all cases the table is visible to and accessible by the user, the only difference is what he can do with it.

The Security Filter on the other hand controls whether a user will have any visibility at all of the table. If the user is not allowed by the Security Filter expression, this table will not even be downloaded on the user’s device. As if it just didn’t exist.

3

Ok Joseph, thank you, I still have a question, for example, how is the filter that I should write so that only the administrator has access to the tables and not the common user. I am not referring to the CRUD (create, edit, update and delete) but the part below. I send you an image of the part that I say.

Sin título2.png
Sin título2.png960×611 46.4 KB

In Security Filter (Appsheet core) that I should to write? Is there an app where I can see the written example?

4

You can for example use: USERROLE() = “Admin”.

5

¡Vale José! en este caso solamente el admin (o sea yo) tiene acceso a la hoja de cálculo? Sería como que el usuario estuviera utilizando una app con solo “columnas virtuales”. Este no podría descargar la hoja, es así?

6

Hola Gus,

Es posible que estemos hablando de dos cositas distintas.

Primero, nadie podrá acceder directamente a tu hoja de cálculo sin que se lo des explícitamente el acceso.

Sin embargo, cuando tu hoja de cálculo está conectada a una app de AppSheet, los usuarios de tu app tendrán acceso a los datos guardados dentro de tu hoja de cálculo, sin tener un acceso directo a la misma. Los Security Filters controlan a qué datos un usuario de tu app podrá acceder. Pero un usuario que tiene acceso a tus tablas (los datos) en la app seguirá sin tener acceso a tu hoja de cálculo.

La expresión que pones en el Security Filter de una tabla es la manera de controlar el acceso a los datos de esa tabla. Hay dos maneras de aplicar ese control:

  1. Acceso global: Basándose en el email del usuario, permitirá o impedirá el acceso a la totalidad de la tabla. Por ejemplo: USERROLE() = “Admin”, o USEREMAIL() = “gus@mail.com”.

  2. Acceso parcial: Teniendo en cuenta que a condición del Security Filter se evalúa por fila, será posible por lo tanto permitir el acceso a unas filas de la tabla que cumplen la condición. En este caso, la fila debe tener una información en una columna que permite identificar el usuario, como su email o su departamento. Por ejemplo: USEREMAIL() = [email], o IN(“Gestión”, [email].[niveles de acceso]).

Las columnas virtuales son otra cosa. Es verdad que no están en la hoja de cálculo, pero un usuario podrá ver sus datos (y exportarlas) si no hay un Security Filter que lo impida.

7

Punto número 1 creo que aclarado, me va quedando mucho más claro.

Digamos que la app tiene tablas generales y slices.

Los slices son simplemente filtrados para mostrar en UX (que admiten filtrado por usuario) sin embargo, en caso de no existir security filter, cualquier usuario podría leer todos los datos de todos al exportar.

Ahí es donde entraría en acción el security filter entiendo yo. que lo que busca hacer es crear un dominio para cada usuario, es decir, cada fila tiene su dueño, por así decirlo.
cómo me explicas, podría impedir esa visualización a todos los usuarios de forma global creando la condición Userrole()=admin o mi Usermail=Gus@email.com que es lo que ahora uso, o bien de forma parcial tal como lo hago con los slices para visualizar en UX, poniendo por ejemplo userID=Usermail()

todas mis tablas evitables que no son generales tienen una columna userID de forma que quien carga un dato queda registrado.

con el security filter evitaría que alguien descargue algo que no es suyo entonces.

Punto número 2, he leído qué se puede crear una hoja de cálculo privada para cada usuario en caso de apagar el botón (share) que viene por defecto. Sin embargo ese no es mi caso, prefiero que haya una sola hoja de cálculo alojada en mi cuenta y que todos los datos vayan ahí. Tengo entendido que si dejo activado share esta hoja de cálculo solo funcionaría en mi nube y nunca se crearía una tabla clon para nadie.

según lo que te entendí, Joseph, nadie puede acceder a esa hoja de cálculo en mi nube de forma directa ni a todos los datos si pongo como condición IdUsuario=Usermail(), en ese caso cada usuario dispondría solamente de sus datos tal como un slice. puede ser? Solamente que en este caso no solo se trataría de una visualización sino también de seguridad.

en este momento estoy usando un security filter:

USERROLE()=“Admin”

En este último caso solo yo dispondría de los datos y nadie más dispondría de ningún dato de nadie (salvo en su app). Es así?

un abrazo amigo me voy a dormir mañana leo la respuesta! Saludos buenas noches perdón mi dureza pero agradezco siempre tus respuestas

8

Sí.

con el security filter evitaría que alguien descargue algo que no es suyo entonces.

¡Correcto!

Punto número 2, he leído qué se puede crear una hoja de cálculo privada para cada usuario en caso de apagar el botón (share) que viene por defecto.

Las Private Tables son otra cosa, donde tú como creador de la app no tendrás acceso a la tabla del usuario.

Tengo entendido que si dejo activado share esta hoja de cálculo solo funcionaría en mi nube y nunca se crearía una tabla clon para nadie. según lo que te entendí, Joseph, nadie puede acceder a esa hoja de cálculo en mi nube de forma directa ni a todos los datos si pongo como condición IdUsuario=Usermail()

Correcto.

, en ese caso cada usuario dispondría solamente de sus datos tal como un slice. puede ser? Solamente que en este caso no solo se trataría de una visualización sino también de seguridad.

Con o sin slice, toda la tabla ya esta cargada en el dispositivo del usuario. Un slice es un filtro sobre datos que ya son accesibles y disponibles.

Un Security Filter es un filtro que determine desde el principio qué datos serán accesibles.

en este momento estoy usando un security filter:> > USERROLE()=“Admin”> > En este último caso solo yo dispondría de los datos y nadie más dispondría de ningún dato de nadie (salvo en su app). Es así?

La tabla donde tienes este filtro configurado será accesible por todos los usuarios de la app configurados con role “Admin” en el editor de la app.

Espero que te sea útil amigo.

9

Hi Friend!

This type of answer is not only useful for me, but also for the entire community since it is a detailed answer, where each point of the question has an answer (as is now the case on the networks and on whatsapp) it is very practical . I think this is a little explored and exploited topic.

The last question I have.

Suppose Joseph, that I am not an admin but a user of the app.

The Admin has set the security filter USERROLE()=“Admin” on all tables. I, as a common user, could enter the app and use it normally, that is, could I see the data that I charge from my cell phone (without downloading anything)?

I have been testing below, placing an email from a user to see how he sees the application and I have seen that he can load data into the spreadsheet through the app in all views without problem (which is what I needed). We already know that the chosen security is USERROLE()=“Admin”

10

Yes, if the user has access to a form view of this table, and the CRUD settings of the table allows the user to add records, the user will be able to add new rows to the table without seeing any. existing rows.

Please note that there is a security setting called Filter out all existing rows which does the same thing albeit for all user, so all users without distinction will be able to add rows but none of them will be able to see any existing rows in the table even his own-added rows.

This is equivalent to having a Security Filter set to FALSE, but without the need of Core subscription.

11

Agradezco mucho tus respuestas Joseph! un saludo desde Argentina amigo.

12

Un abrazo desde España :blush:

13

Joseph, podría poner yo esta condición de filtrado?

[UserID]=USEREMAIL()

Podría ser algo así también.. cual de las dos te parece mejor?

IFS(

USERROLE() = “Admin”,
“”,

USERROLE() = “User”,
[Id Usuario]=USEREMAIL()

)

Considerando que las filas carguen en función de lo que el usuario ha escrito con el fin de mejorar la sincronización?