Glosario
Usuario de solo lectura: ver sin poder tocar
Definición
Un usuario de solo lectura es una cuenta de tu ERP, tienda o base de datos que puede consultar información pero no crear, modificar ni borrar nada. Se logra dando solo permiso de lectura, separado de los de escritura, que se conceden aparte. Es el principio de mínimo privilegio aplicado a una integración: si la clave se filtra o el sistema conectado falla, tus datos no se pueden alterar, y tu contabilidad y tu stock quedan como están.
Para que un sistema externo calcule tus reposiciones no necesita escribir nada en tu programa. Necesita mirar. Un usuario de solo lectura es una cuenta que ve los datos y no puede cambiar ni una coma, y es la condición mínima para conectar cualquier cosa con seguridad.
Qué es exactamente
Un usuario de solo lectura es una identidad con permisos limitados a consultar. Puede ver productos, existencias, ventas y compras. No puede crear un pedido, ajustar un inventario ni borrar un albarán. Cualquier intento de escribir se rechaza.
Detrás está el principio de mínimo privilegio: cada cuenta recibe solo lo que necesita para su trabajo. Una herramienta que calcula y propone no necesita escribir, así que no debe poder.
También se le llama
Acceso de solo lectura, read-only user, cuenta de consulta o permiso de lectura. En bases de datos, se concede con el privilegio SELECT; en un ERP, con un perfil de acceso sin permisos de escritura; en una tienda online, con una clave de API limitada a lectura.
Un ejemplo
Una empresa de suministros industriales con Odoo quiere conectar un sistema de reposición. En su servidor de base de datos PostgreSQL se crea un rol nuevo y se le concede SELECT sobre las tablas de productos, ventas, compras y existencias. En PostgreSQL, SELECT es el privilegio que permite leer una tabla, y INSERT, UPDATE y DELETE se conceden aparte, cada uno por separado, y ninguno implica el de lectura. Como el rol no los recibe, no puede escribir, aunque quiera. Incluso se puede limitar a columnas concretas: el sistema ve el coste del producto, pero no los datos personales del cliente.
En Odoo, desde la aplicación, el equivalente es un usuario cuyo nivel de acceso a cada aplicación permite leer y no escribir. Los derechos de acceso cubren cuatro operaciones (leer, escribir, crear y borrar), y se puede dar solo la primera. Un administrador es quien los reparte.
Ojo con esto
Lo que conviene comprobar antes de dar por segura una conexión:
- Probar que no escribe: pide que intenten un cambio con esa cuenta y comprueba que falla. Es más fiable que fiarse del nombre del perfil.
- No reutilizar la cuenta de un empleado: una cuenta personal con permisos amplios, prestada a una integración, hace que cualquier fallo tenga el alcance de esa persona.
- Mirar también lo que se lee: solo lectura no significa que no vea datos sensibles. Limita tablas y columnas a lo que hace falta: stock, ventas y compras, no clientes con nombre.
- Poner caducidad y rotación: las claves se cambian cada cierto tiempo y se revocan cuando acaba el proyecto.
- Las secuencias y otros objetos tienen permisos aparte: en PostgreSQL, el permiso sobre una tabla no da acceso a sus secuencias, así que a veces falla una lectura aunque la tabla esté bien.
Dónde aparece en el sistema
Es el único acceso que pedimos. Todas las conexiones (Odoo, Business Central, Sage, Holded, SAP Business One, Shopify, WooCommerce, PrestaShop, Power BI o ficheros) se hacen con una cuenta que solo lee. El sistema calcula y propone; quien aprueba y escribe en el programa eres tú.
Eso permite empezar sin tocar nada y sin riesgo: la simulación con tus datos y el modo sombra usan los mismos permisos, y si lo dejas, retiras la cuenta y no queda nada abierto. Los datos viven en la UE, con copias diarias y exportación completa.
Términos relacionados
ETL, almacén de datos, modo sombra, backtest y integración entre ERP y tienda online.
Preguntas frecuentes
¿Puede el sistema cambiar nuestro stock sin que lo sepamos?
No. Con una cuenta de solo lectura, el programa rechaza cualquier escritura. Las propuestas las revisa una persona y, si se aprueban, las registras tú en tu programa.
¿Cómo creamos el usuario?
Depende del programa. En una base de datos, un rol con el privilegio de lectura; en un ERP, un usuario con permisos de consulta; en una tienda, una clave de API de solo lectura. Te guiamos en cada caso y lo comprobamos juntos.
¿Qué hacemos al terminar la colaboración?
Se revoca la cuenta o la clave y se eliminan los datos o se te entregan en una exportación completa, a tu elección. No queda ninguna conexión abierta.