Multi-usuario

Con los últimos avances de @pierre-gilles y de todos los desarrolladores desde el regreso de vacaciones, Gladys V4 está casi lista para pasar a RC. Lo único que realmente falta para mí para un uso completo en casa (hablo por los usuarios del hogar), es el multiusuario y, por lo tanto, la configuración personalizada de cada uno en el Dashboard.

Al estar casi al 100% en la V4 (excepto por la barrera), esta falta está empezando a crear tensiones (afortunadamente modestas) en casa para decidir:

  • qué cámara mostrar en primer lugar,
  • qué dispositivo y en qué orden,
  • etc.

Lo cual es muy buena señal, por cierto, porque significa que Madame se interesa plenamente.

Sin embargo, inutilizable en el ámbito profesional por nuestros profesionales de la salud mientras esta función no esté presente. Por lo tanto, mantengo un pie en la V3 para la gestión de los modos también.

@Terdious Muy interesante tu comentario, porque lo que expresas como necesidad no es que te falte el multiusuario, ¡es que te falta el multi-dashboard!

Para mí son dos cosas diferentes, que sí vamos a hacer, pero hay que priorizar.

¿Podrías hacer otro mapa para el multi-dashboard y hablar de tu caso de uso allí? :slight_smile:

Ah … entonces debí equivocarme en la visión de las cosas, porque para mí también se trata de dos cosas distintas, pero yo hablo del multi-usuario.

  • El multi-panel de control, en todo caso en lo que yo entendía y esperaba, es tener varios paneles de control configurables en cada cuenta de usuario.
  • El multi-usuario es poder, como en Gladys V3, poder conectarse cada uno con su dirección de correo electrónico o nombre de cuenta y tener sus propios paneles de control, en este caso hoy su panel de control principal, así como sus escenas, su calendario, su owntrack.
Para el caso de hoy en la v3 tengo esto:

y por lo tanto cada profesional se conecta a su cuenta, cuyo panel de control he preconfigurado con lo necesario. Al final, pensé que no se necesitaba el multi-panel de control para esto;

Pensé que en la base de datos

image

[details=" En la columna selector podías poner el nombre de la cuenta y « _main » (aquí « thomas_main »)"]
image|690x175
[/details]
Esto deja luego espacio para definir el multi-panel de control.

Claro, también contaba con hacerlo, pero no tuve tiempo esta mañana ^^ porque esto también me interesa personalmente ^^

Mmm vale. Recuerda que tu caso de uso es realmente muy muy particular :smiley: Pero hay que tenerlo en cuenta, intentando no complicar demasiado para la mayoría que está en una situación simple.

Mi visión para la v4 era precisamente simplificar, simplificar, simplificar. En la v3 todo era « por usuario », y francamente era demasiado complejo. Gladys es un producto que la mayoría instala « en un círculo de confianza », por lo que quería evitar la trampa de la sobrecomplejización de las reglas de derechos.

Para los dashboards, por ahora la función de dashboard se ha diseñado en modo « público ». Puede haber varios dashboards, visibles para todos.

Habrá que discutirlo (quizás en una llamada comunitaria con varios?), me pregunto si queremos:

  • Hacer los dashboards personales
  • o dejar los dashboards públicos, y cada uno puede elegir su dashboard por defecto.

Hola @pierre-gilles,

De hecho, creo que podría ser interesante hacer una llamada comunitaria, integrando este punto en particular, pero quizás podrías crear un hilo para preparar esa llamada con el fin de agrupar varios temas. Por mi parte, estoy muy interesado en estas llamadas ^^ Si tienes tiempo, ¿sería posible programarlas de manera recurrente nuevamente?

De hecho, para este caso en particular (quiero decir, profesionales de la salud), es muy particular. Pero eso era solo un ejemplo de un caso particular para mostrar que cada uno puede tener uno, y que si Gladys puede lograr gestionar esta flexibilidad, al tiempo que tener una manera simple de configurarlo, puede interesar a mucha gente.

Estoy totalmente de acuerdo, y desde el principio, con la visión y la construcción que haces de Gladys. Pero sobre todo con la línea de conducta a seguir y, en particular, la documentación, que se está convirtiendo poco a poco en un punto de los más importantes. Pero, en mi humilde opinión, esto no debe impedir gestionar cosas un poco más precisas. Porque en este caso se excluye a una gran parte de la población. Y, en mi humilde opinión, incluso dentro de un « círculo de confianza », no deberíamos « prohibir » al usuario ir más allá.

Bueno, me quedo con el caso del Multi-usuario y me permito dar 2 ejemplos:

  1. Soy un usuario lambda, uso Gladys solo o en pareja
    Condición previa: Haber implementado en el lado DEV un « Tipo de Escena » que puede ser de Tipo « Principal » o « Cuenta de Usuario » en la DB + en la tabla « t_scene » haber añadido una columna Tipo de Escena o bien automatizar la columna Selector para integrar el Tipo de Escena.

    Puedo:

  • crear mi cuenta (Admin por defecto), dar acceso a mi/esposa/esposo y compartir todo. No hay nada más que configurar en comparación con hoy. Cuando creo una escena, de todos modos se crea como « Principal »
  • crear 2 cuentas (Admin por defecto - nada que tocar adicionalmente en comparación con ahora, al crear la cuenta se propone por defecto el tipo Admin), cada uno con su cuenta y:
    • configurar su panel de control a partir de todos los dispositivos creados,
    • cada uno configura su Agenda (vinculada a su cuenta de correo / agenda),
    • cada uno puede crear y ver / modificar escenas del tipo « principal » (lista desplegable al abrir las escenas que ofrece los tipos "Principal / Cuenta de usuario [es decir, tener en cuenta el creador de la escena] que puede ser definido en el lado del desarrollador en una nueva columna de la DB o añadiendo « _main » o « _nombrecuenta » al selector si no queremos tocar la DB.
    • cada uno configura sus escenas en la Agenda (mensajes enviados a la cuenta de Telegram configurada, por ejemplo) en tipo « Cuenta de Usuario ».
  1. Soy un usuario que quiere equiparse completamente con domótica y utilizar plenamente la seguridad y la facilidad de automatización que puede ofrecer la domótica:
    Condición previa: Igual que 1. + Haber creado una tabla « Tipos de cuentas de usuario » + Desarrollar una página para definir (de manera simple, esto puede ser en la parte superior de la página un campo donde se escribe el nombre del tipo de cuenta con un botón « Nuevo » y debajo la lista de tipos de cuentas con un botón « Configurar » al lado) estos « Tipos de cuentas de usuario » para definir lo que pueden ver / modificar (por ejemplo, ocultar todas las vistas excepto el Panel de control; ocultar las escenas de tipo « Principal » pero dejar que el usuario cree sus propias escenas; etc.) todo esto de manera simple (por ejemplo, casillas de verificación) + Añadir una columna en la tabla t_device o t_device_feature de la DB de tipo múltiple para poder definir los tipos de cuentas que pueden acceder a ella.

Por lo tanto, puedo:

  • Crear mi cuenta Admin,

  • Crear una cuenta Admin para mi pareja, idéntica al punto 1.

  • Crear un Tipo de cuenta « Adolescentes », mi hija/hijo tiene 16 años y conoce la domótica, le dejo acceso a las vistas Panel de control / Chat / Integraciones / Calendario / Mapas / Escenas y le dejo acceso solo a las integraciones de tipo Calendario / Comunicación. Para su Panel de control, le dejo la posibilidad de mostrar el Clima / la Presencia del Usuario en la Casa / a los Dispositivos de las habitaciones comunes y de su habitación pero no de nuestra habitación ni de los dispositivos automatizados / A las cámaras principales pero no a todas / A sus propias Escenas pero no a las Escenas definidas como tipo « Principal »,

  • Crear un Tipo de cuenta « Niños », mi hija/hijo tiene 10 años y se inicia en la domótica, le dejo acceso a las vistas Panel de control / Chat / Mapas. Para su Panel de control, le dejo la posibilidad de mostrar el Clima / la Presencia del Usuario en la Casa / a los Dispositivos de las habitaciones comunes pero no a la televisión y de su habitación pero no de nuestra habitación ni de los dispositivos automatizados / A la cámara del gallinero, por ejemplo, pero no a las otras / A sus propias Escenas pero no a las Escenas definidas como tipo « Principal »,

  • Crear un Tipo de cuenta « Invitados de confianza », mis amigos/familia que pasan de vez en cuando quieren poder gestionar la música, la televisión o un ambiente, de vez en cuando vienen a la casa a pedirme prestado una herramienta pero no estoy allí a menudo, les dejo acceso a las vistas Panel de control / Escenas. Para su Panel de control, dejo la posibilidad de mostrar el Clima / No la presencia del usuario / a los Dispositivos de la sala de estar, del exterior y del garaje, en particular la cerradura de la puerta de esta última habitación así como la barrera pero no al resto / No a las cámaras / A la Escena tipo « Principal » pero le prohíbo definir sus propias escenas,

  • Crear un Tipo de cuenta « Limpieza », tengo una mujer de limpieza que viene 1 vez por semana el Martes entre las 13h y las 16h, le dejo acceso solo a la vista Panel de control que voy a definir con los Dispositivos de la barrera, la cerradura electrónica de la puerta de entrada de la casa, las luces de la casa, la música y la válvula de agua de la cocina pero a nada más. Activaría su cuenta (a través de una escena, por ejemplo) el Martes a partir de las 12h y desactivaría la misma cuenta a partir de las 19h (hora de mi regreso - por si termina más tarde un día) ese mismo día,

  • Crear un Tipo de cuenta « Mantenimiento exterior », tengo un jardinero que viene 3 veces por semana los Lunes, Miércoles, Viernes entre las 17h y las 18h30, le dejo acceso a las vistas Panel de control / Escenas con los Dispositivos: la barrera, la cerradura electrónica de la puerta del garaje y la de la invernadero (sí, hay herramientas dentro ^^), las luces del garaje, del exterior (para el invierno) y de la invernadero, la música exterior (eso realmente lo tengo ^^), el enchufe de la bomba del pozo y las válvulas de alimentación de agua de los caballos, de la invernadero y de las plantas exteriores. Activaría su cuenta los días correspondientes a partir de las 16h30 y desactivaría la misma cuenta a las 18h35 (no quiero que termine más tarde un día) esos mismos días,

Ejemplos profesionales
Para @Shermi (en Slack):

  • Crear un tipo de cuenta « Clientes », tengo un pequeño hotel con 10 habitaciones y he instalado cerraduras conectadas en cada puerta. Creo una cuenta de usuario por habitación y puedo modificar la contraseña de cada cuenta desde mi cuenta de administrador. Gracias a una configuración previa, puedo crear escenas por habitación para gestionar ambientes a los que tendrá acceso solo en la vista del Dashboard, y referenciar una cuenta de Telegram y desactivar la vista de las Integraciones. Un cliente reserva para la semana, activo la cuenta para el mismo período y le doy el par nombre de cuenta/contraseña al llegar, tiene acceso a través de la dirección https configurada por el administrador directamente a su puerta de la habitación, al mando a distancia de la televisión y a todo lo que pueda estar domotizado en su habitación, así como al inicio de las escenas vinculadas a la cuenta (por lo tanto, a la habitación). ¿Por qué no también, a través del chat, hacer solicitudes directas para pedir su desayuno especificando su número de habitación. Cuando su estancia termine, desactivo la cuenta.

Para mí:

  • Crear un tipo de cuenta « Gabinete Profesional n°1 », tengo un gabinete médico compartido por 2 profesionales que comparten nuestro portal de entrada. Creo una cuenta de usuario por profesional. Les doy acceso a las vistas Dashboard/Chat/Integraciones/Calendar/Maps/Scenas y les dejo el acceso a las Integraciones solo de tipo Calendar/Comunicación. Para su Dashboard, les dejo la posibilidad de mostrar el Clima/los dispositivos del portal, iluminación exterior, de su gabinete, de la sala de espera y los baños/La cámara del portal (Llegada del paciente al timbre = seguridad)/A sus propias Escenas, pero no a las Escenas definidas como tipo « Principal », así puedo configurar en cada una de sus cuentas, vinculadas a su cuenta, la automatización de la iluminación y del portal según sus horarios de trabajo a través del Agenda,

  • Crear un tipo de cuenta « Ubicación de Camping », en el mismo orden de ideas que el ejemplo del hotel anterior para gestionar las ubicaciones de forma independiente.

(Todo esto son solo ejemplos de lo que podría considerarse, aún no tengo hijos, pero viendo lo que hemos podido leer en el foro durante todos estos años, imagino los casos de uso para algunos)

Ahí está, lo siento, muchos ejemplos, pero prefería hablar de todo lo que tenía en mente sobre este tema. Y en cuanto a la experiencia del usuario, para el punto 1., no cambia nada con respecto a hoy. Todo se crearía automáticamente en « Admin », todas las opciones marcadas de base, todos los dispositivos accesibles para todos los usuarios y todas las escenas creadas en « Principal ». La configuración sería solo en el sentido descendente. Luego, en la vista de creación de un usuario, bastaría con poner un enlace a la documentación (ej.: « Para seguir aprendiendo ») y explicar cómo configurar todo esto solo si se desea configurar cuentas de manera específica.

PS: Es cierto que en cuanto a desarrollo requiere tiempo, pero en mi opinión las posibilidades de domótica completa, pero también de boca a boca y de demostración serían enormes.

¡Hola a todos!

Acabo de terminar el desarrollo de las variables inyectadas en las escenas, y ahora me lanzo a esta función que es una de las más solicitadas :slight_smile:

He escrito especificaciones funcionales y diseñado algunas capturas de pantalla, y quería ver con ustedes qué les parece.

Especificación funcional

Como primer usuario de una instancia Gladys, soy por defecto « administrador ».

Este usuario tiene la posibilidad de crear otros usuarios, otros « administradores » o otros « usuarios »

  • Administrador: El rol por defecto del primer usuario de Gladys, tiene todos los derechos.
  • Usuario: Un usuario tiene un rol restringido con menos derechos. Le son ocultadas y bloqueadas: Todas las integraciones de la categoría « Dispositivos » y « Clima ». Puede configurar las integraciones « Telegram » y « Caldav ». La pestaña « Configuración » le es oculta.

Crear un nuevo usuario

El administrador va a « Configuración » => « Usuarios »

Puede crear un usuario y definirle una contraseña. Se considera que, estando en un círculo de confianza (la familia) + por simplicidad de configuración, el hecho de que el administrador defina la primera contraseña del usuario no es un problema (el usuario puede modificar esta contraseña más tarde)


Editar un usuario

Editar un usuario existente

Cada administrador puede editar los usuarios, incluidos otros administradores. Puede editar tanto su perfil como sus preferencias.

Eliminar un usuario

Cada administrador puede eliminar un usuario. Un administrador no puede eliminarse a sí mismo.

Visibilidad de los diferentes datos

Los dashboards

2 tipos de dashboards:

  • Privado (accesible solo por el usuario que lo creó)
  • Compartido (accesible por todos los miembros de la instancia Gladys)

Cada usuario tiene un dashboard privado « por defecto ». Veremos la utilidad de los dashboards compartidos, quizás no sea necesario en un primer momento…

Las escenas

A discutir: Las escenas son compartidas por toda la familia. Cada uno puede crear escenas y ver las escenas de los demás.

Otra posibilidad: Las escenas son completamente privadas. Cada persona solo ve sus escenas.

Chat

La conversación con Gladys es entre el usuario y Gladys. Es completamente privada.

¡Qué funcionalidad tan práctica!

Yo la parte que encuentro más oscura es la parte de los derechos. Bloqueas las integraciones (configuración de servicios), vale, pero también puedes negar que una persona acceda a información específica. Por ejemplo, acceso a la apertura del portal, acceso a ciertas cámaras, acceso a una caja fuerte conectada, etc.

Entonces, ¿cómo gestionar esta parte?

Por lo demás, me parece bien.

¿Realmente queremos esto?

Es muy pesado, complica el producto en todos los sentidos.

Para información, incluso Apple no lo hace en Homekit según lo que he entendido:

Yo sí :smiley:

Estoy de acuerdo contigo, es muy pesado. Pero si más tarde se pide esta función será un desastre integrarla …

Pero entiendo el punto de vista :slight_smile:

¿Entiendo el requisito, sería suficiente una lista de dispositivos « blacklistados » por usuario?

Ejemplo:

El usuario A no tiene permiso para usar el dispositivo X. No verá el dispositivo en ningún lugar y no podrá controlarlo.

Los problemas que veo son:

  • Los dashboards compartidos: ¿qué pasa si compartes un dashboard con alguien cuyo dispositivo utilizado en el dashboard está en la lista negra?
  • ¿Qué pasa con los comandos de voz? Si un dispositivo está en la lista negra para un usuario, ¿significa que está en la lista negra en los sensores de voz « públicos no autenticados » de la casa, ya que no podemos saber quién habla?
  • Escena: Hay que asegurarse de que un usuario no tenga un medio de control indirecto de un dispositivo en la lista negra.
  • Todos los desarrollos futuros deberán tener siempre en cuenta estos permisos.

En principio, no estoy en contra, pero me parece que la gestión de derechos es sobre todo una utopía que cada uno se hace en modo « quiero controlar todo », y en la realidad es sobre todo un lío que hace que el uso del producto y el desarrollo sean 2 veces más complejos.

Incluso Apple no lo hace, francamente me da miedo :sweat_smile: Tienen cientos de ingenieros a 200k el año trabajando en ello desde 2014, y después de tantos años aún no lo hacen :stuck_out_tongue:

¡Sí, completamente! Para mí hay que dar la posibilidad de no controlar ciertos equipos. Por ejemplo, en tu casa tienes una cerradura conectada. Vas a tener invitados, les das acceso a Gladys. No quieres que esos invitados desbloqueen tu puerta de entrada. Yo lo veo así.

Blacklistear es una buena idea y en cuanto a integración es bastante « fácil ».

Quizás no se les ocurrió / no le dieron importancia :slight_smile:

¡Hola!!

¡Vaya!! ¡No me lo esperaba tan rápido!! ¡Qué buena noticia.

Por mi parte, mi opinión no es muy importante, ya que todos sabemos el uso que quiero darle a Gladys y no debo dejar que mi interés personal influya demasiado.

Sin embargo, incluso dejando de lado el aspecto profesional, etc., estoy de acuerdo con @damalgos.

  1. Es cierto que hay invitados, pero no solo eso. Podemos empezar por los niños. La accesibilidad de Gladys y su simplicidad (que es su mayor ventaja y en la que estás muy enfocado @pierre-gilles - y ahora nosotros también) pueden llevar muy rápidamente a poder integrar, por ejemplo, la barrera, o como dice @damalgos, en el panel de control para un niño. Pero también la gestión del calefacción del apartamento / la casa, etc. etc.!! y más.
  1. Desde el punto de vista del administrador/usuario, en absoluto. Partimos de la base de que queremos algo simple, de acuerdo, y bien, basta con que sea solo una posibilidad y no una obligación. Con tu idea de lista negra de dispositivos, ningún problema. El usuario que no necesite esta gestión de derechos no toca absolutamente nada. Al final, solo los desarrolladores como nosotros tendremos un poco más de trabajo.
  1. Y no solo Apple, lo mismo para Alexa (la uso y no he encontrado nada similar), sin embargo, muchas personas lo critican. Pero tampoco hacen el mismo producto que Gladys, creo que será un punto fuerte que podrás destacar.

  2. Efectivamente, hay que ver a dónde nos lleva esto para la gestión de las escenas, etc. En un primer momento, si se implementa este punto de los derechos, se tratará de hacer solo lo privado para los paneles de control y las escenas. Después solo queda poner los cerrojos en función. Para el chat, también.

En cualquier caso, lo que presentas ya es muy atractivo, me encanta ^^ ¡Me encantaaaaa! ^^

Mi idea sobre los derechos (puede que sea una mala idea)

Tener una página sobre el usuario con los derechos que el administrador concede o no:

Escena:

  • Autorización para crear una escena: sí/no
  • Autorización para eliminar una escena: sí/no
  • Autorización para iniciar una escena: sí/no
  • Autorización para visualizar las escenas: sí/no

Panel de control:

  • Autorización para modificar el panel de control: sí/no
  • …

Integraciones:

  • Autorización para añadir una integración: sí/no
  • Autorización para eliminar una integración: sí/no
  • Autorización para modificar una integración: sí/no

Al crear una escena:

  • Autorización para usar la escena concedida a: usuario
    Un ejemplo en imagen:

Me encanta la idea. Solo una cosa, ¿cómo permitir que un administrador configure el panel de control de un usuario que no tiene permiso para hacerlo? Pero es la solución más « fácil » de implementar y además no perjudica al desarrollo.

Para mí, creo que dependerá de la persona:

  • mi pareja (meteorología, calefacción, luces de la casa, cámara interior y exterior)
  • mi hijo (música, luz de su habitación, temperatura de su habitación, sin modificar la calefacción)

Respondía en relación a este permiso. Si tu hijo no tiene autorización para modificar el panel de control (sin botón de editar), hay que definir cómo podremos modificar este panel de control.

Ese es un argumento para no hacerlo :stuck_out_tongue: No es una sorpresa que Apple/Amazon consigan millones de usuarios en su producto: es simple y va al grano.

Si no le dan importancia, es que al final no era tan importante y seguramente había funcionalidades más importantes a las que dedicaron sus recursos (¡y ellos tienen muchos recursos! :p)

No hay que olvidar que por cada funcionalidad que desarrollamos, hay una funcionalidad que no desarrollamos.

Es simple: la comunidad ha votado, es una de las funcionalidades más solicitadas, así que la hago :slight_smile: Vamos avanzando progresivamente en la lista, ¡qué alegría!

Sin embargo, tienen millones de usuarios, por lo que la simplicidad de uso de su solución ha funcionado.

Uf, una matriz de derechos es justo lo que quiero evitar. Por experiencia en desarrollo de software, es simplemente un infierno (tanto para la experiencia del usuario como para el desarrollador).

Bueno, he reflexionado, y para mí son realmente dos temas diferentes: el multi-usuario y la gestión fina de los derechos en los dispositivos.

Siempre es algo que se puede añadir más tarde (no será más complicado que añadirlo ahora).

Por lo tanto, mi opinión:

  • Mantener la funcionalidad « multi-usuario » sola, sin complejidad. Sin gestión de derechos en los dispositivos, sin lista negra. De modo que evitemos un efecto túnel de 3 meses, y que el multi-usuario + multi-dashboard pueda salir rápido.
  • Una vez que tengamos el multi-usuario, creamos una tarjeta en « feature request » para la historia de la lista negra de dispositivos, y será priorizada por la comunidad frente a todo lo demás.

Prefiero dividir las funcionalidades en pequeños desarrollos para poder lanzar cada semana o cada dos semanas como hemos hecho desde el principio, al menos somos capaces de iterar en ciclos cortos y evitamos los desarrollos infinitos que no avanzan :slight_smile:

Sí y no. Apple / amazon / … apuntan al gran público con un máximo de funcionalidades básicas, compatibilidad y un funcionamiento global muy bueno. Sin embargo, Gladys apunta a usuarios que potencialmente quieren ir un poco más allá en la configuración. Escenas, gestión de todos los equipos entre sí con cierta coherencia. (no solo otros puntos en cuanto a control de datos, DIY, …)

Estas empresas piensan en términos de coste. Pero la necesidad sigue estando presente.

El problema en este ejemplo es que la necesidad es diferente. Alguien que vaya a comprar un altavoz Alexa, quiere, ante todo, un dispositivo para realizar acciones cotidianas sin casi nunca configurar domótica (temporizador, radio, música). Con la fuerza de la notoriedad / publicidad, etc. de estas empresas, ¡por supuesto que dominan! Y, sin embargo, no cubren todas las necesidades. Por eso, en domótica, hay otros actores que a veces son más pertinentes.

Pero estoy de acuerdo contigo en que en dos etapas puede ser perfecto :slight_smile:

No sé por el lado del desarrollador, pero por el lado del usuario una vez que está configurado, ya no se toca más.
Si el usuario quiere acceder a otra integración, la administración puede o no activarla.

En 2 pasos, está bien, te deja tiempo para pulirlo.