Escribir un permiso propio

Lo que se genera solo

Al declarar el manifiesto, el framework produce un permiso por comando con un nombre derivado del suyo:

cargar_proyecto     →  allow-cargar-proyectoguardar_proyecto    →  allow-guardar-proyecto

Y con eso ya funciona todo lo del nivel 29.1. Lo que sigue es para cuando esa lista deja de ser manejable.

Un permiso escrito a mano

Los permisos propios viven en un directorio y se escriben en un formato de configuración sencillo:

# src-tauri/permissions/proyectos.toml[[permission]]identifier = "leer-proyectos"description = """Permite listar los proyectos y cargar el contenido de uno.No permite escribir: eso es escribir-proyectos."""commands.allow = ["listar_proyectos", "cargar_proyecto"][[permission]]identifier = "escribir-proyectos"description = "Permite crear, guardar y borrar proyectos del directorio de datos."commands.allow = ["guardar_proyecto", "borrar_proyecto"]

Tres campos y los tres importan:

Los conjuntos

Cuando varios permisos se conceden casi siempre juntos, un conjunto los agrupa:

[[set]]identifier = "proyectos-completo"description = "Todo lo necesario para trabajar con proyectos: leer, escribir y exportar."permissions = ["leer-proyectos", "escribir-proyectos", "exportar-proyectos"]

Y aquí conviene una advertencia que el nivel 26.5 ya anticipó: un conjunto es cómodo y es donde se concede de más. La regla que los hace útiles en vez de peligrosos:

• Un conjunto agrupa permisos del mismo nivel de riesgo. Leer y escribir en el mismo directorio, sí. Leer ficheros y ejecutar procesos, no.
• Y el conjunto de solo lectura existe siempre. Si hay un conjunto completo, tiene que haber uno de lectura, porque la mitad de las ventanas solo van a leer.

La convención de nombres

La lista de permisos acaba siendo un vocabulario, y conviene que se lea:

verbo-dominio            leer-proyectos, escribir-proyectos, exportar-catalogoverbo-dominio-acotado    leer-proyectos-propiosdominio-completo         proyectos-completo     (los conjuntos)

Tres reglas que lo sostienen:

El verbo primero. Al ordenar alfabéticamente, los de lectura quedan juntos y los de escritura también, que es como se revisa.

El dominio, no el mecanismo. Es el criterio del nivel 14.4 otra vez: leer-proyectos dice qué se puede tocar; usar-fs no dice nada.

Sin el prefijo allow. El framework lo pone al resolver, así que escribirlo produce nombres duplicados. Los permisos generados automáticamente sí lo llevan porque los nombra el framework.

Qué gana la capability

Con permisos propios bien nombrados, una capability pasa de esto:

"permissions": [  "core:default",  "allow-listar-proyectos", "allow-cargar-proyecto",  "allow-guardar-proyecto", "allow-borrar-proyecto",  "allow-exportar-proyecto", "allow-sincronizar-catalogo"]

a esto:

"permissions": ["core:default", "proyectos-completo", "leer-catalogo"]

Y lo importante no es que sea más corto: es que se puede leer. Un revisor que vea la primera lista tiene que reconstruir mentalmente qué puede hacer esa ventana; con la segunda lo sabe de un vistazo, y si quiere el detalle está en un fichero con descripciones.