Redash tourne sur du docker chez nous. C'est proposé nativement avec RootDB ? Ou c'est dans les cartons chez vous ? Ou on peut contribuer pour ajouter ça ?
Il y une image docker prête à l’emploi et en mettant un proxy nginx devant pour gérer les connexions TLS, ça doit fonctionner de base - je pense.
Y a-t-il possibilité de définir la durée de rétention des données ? (Dans une db par exemple). Le cas d'usage : on veut pouvoir générer un graphique sur l'évolution des résultats dans le temps (ce que ne permet pas redash par exemple, et cest bien chiant 🤔 ).
Je comprends la problématique de rétention des données, mais moins le cas d’usage sur l’évolution des résultats dans le temps ?
En l’état il n’y a pas de mécanisme de gestion de retentions des données avec ce projet, mais en définissant clairement le besoin, ça doit pouvoir s’envisager.
Peut-on créer un graphique qui serait le résultat d'un requêtage sur différentes DB (Redash le permet mais cest pas "simple" à faire, voir même plutôt compliqué).
Pas vraiment, désolé :/
Si les base de données sont du même type, par exemple 3 bases de données mysql/mariadb, sur le même serveur, alors oui, il est possible d’écrire des requêtes SQL utilisant ces 3 bases de données.
Mais au delà de ça, non. Ceci dit, nous sommes conscient de cette problématique et j’aimerai bien pouvoir y répondre un jour quand l’architecture pour mettre ça en place sera bien claire dans ma tête :)
Côté config des graphiques, c'est des fichiers de "conf" spécifique genre un par dashboard ? Que l'on peut"modifier" à la volée ?
Les graphiques sont générés par du code javascript modifiable à la volée. Une vue = son code javascript. Quand une vue est créée, avec un type de graphique sélectionné au préalable, du code SQL et javascript est automatiquement ajouté pour avoir une vue fonctionnelle - de base. Cela permet de guider le développeur sur la manière d’écrire sa requête SQL pour récupérer les données.
Est-il possible de gérer des droits d'accès avec compte utilisateur pour rendre la lecture et le rafraîchissement des données possible à un "simple lecteur" ? (Accès pour un client à un dashboard spécifique, partager le rendu avec un accès public).
Il est possible de restreindre l’accès des rapports à un ou plusieurs groupes d’utilisateurs et/ou à un ou plusieurs utilisateurs spécifiques. Un utilisateur peut avoir qu’un rôle viewer, ne pouvant donc qu’afficher les rapports auxquels il a accès, rien de plus.
Les rapports sont également intégrables dans un site externe, avec un lien semi-public, c’est à dire que le rapport n’est affichable que pour une liste de domaines autorisés. (typiquement on autorise que le domaine du site web qui intègre le rapport) Dans cette situation, le rapport s’affiche directement dans le site web externe, sans avoir besoin de se logger.
Après, il doit être possible de mettre en place un véritable accès public à un rapport, sur RootDB directement, ne nécessitant pas de compte pour être visionné.
Possibilité de limiter l'accès en requêtage à certaines bdd ? (pas vraiment vraiment le cas avec redash).
Non, je pars du principe que les restrictions d’accès doivent se faire au niveau des utilisateurs enregistrés, dans les bases de données directement, et qui sont utilisés pour configurer un connecteur côté RootDB.
Après il y a une fonctionnalité qui n’est pas encore activée mais déjà fonctionnelle, en réalité, c’est que RootDB permet de gérer une ou plusieurs organisations. Le terme est peut-être mal choisi mais l’idée c’est que une organisation = son lot d’utilisateurs, développeurs, connecteurs, afin que tout soit bien distinct. (seul le super-admin peut gérer les organisations) Cela pourrait peut-être répondre au besoin, à voir.
Vous proposez des contrats de support pour les entreprises ? (Cest envisageable pour vous ?).
Le projet est tout frais, donc il n’y a pas d’offre de support bien établie mais oui c’est envisageable, il faut voir de quoi on parle précisément. Si t’entends par support, ajouter des fonctionnalités manquantes, oui, clairement ça peut m’intéresser. :)
En tous cas, merci pour toutes ces questions. C’est toujours intéressant d’avoir ce genre de retour, ça permet d’avoir des pistes sur les fonctionnalités à intégrer.
[^] # Re: Docker or not docker, et autres questions.
Posté par gyan000 (site web personnel) . En réponse à la dépêche RootDB - une application web de reporting, auto-hebergée. Évalué à 2.
Il y une image docker prête à l’emploi et en mettant un proxy nginx devant pour gérer les connexions TLS, ça doit fonctionner de base - je pense.
Je comprends la problématique de rétention des données, mais moins le cas d’usage sur l’évolution des résultats dans le temps ?
En l’état il n’y a pas de mécanisme de gestion de retentions des données avec ce projet, mais en définissant clairement le besoin, ça doit pouvoir s’envisager.
Pas vraiment, désolé :/
Si les base de données sont du même type, par exemple 3 bases de données mysql/mariadb, sur le même serveur, alors oui, il est possible d’écrire des requêtes SQL utilisant ces 3 bases de données.
Mais au delà de ça, non. Ceci dit, nous sommes conscient de cette problématique et j’aimerai bien pouvoir y répondre un jour quand l’architecture pour mettre ça en place sera bien claire dans ma tête :)
Les graphiques sont générés par du code javascript modifiable à la volée. Une vue = son code javascript. Quand une vue est créée, avec un type de graphique sélectionné au préalable, du code SQL et javascript est automatiquement ajouté pour avoir une vue fonctionnelle - de base. Cela permet de guider le développeur sur la manière d’écrire sa requête SQL pour récupérer les données.
Il est possible de restreindre l’accès des rapports à un ou plusieurs groupes d’utilisateurs et/ou à un ou plusieurs utilisateurs spécifiques. Un utilisateur peut avoir qu’un rôle viewer, ne pouvant donc qu’afficher les rapports auxquels il a accès, rien de plus.
Les rapports sont également intégrables dans un site externe, avec un lien semi-public, c’est à dire que le rapport n’est affichable que pour une liste de domaines autorisés. (typiquement on autorise que le domaine du site web qui intègre le rapport) Dans cette situation, le rapport s’affiche directement dans le site web externe, sans avoir besoin de se logger.
Après, il doit être possible de mettre en place un véritable accès public à un rapport, sur RootDB directement, ne nécessitant pas de compte pour être visionné.
Non, je pars du principe que les restrictions d’accès doivent se faire au niveau des utilisateurs enregistrés, dans les bases de données directement, et qui sont utilisés pour configurer un connecteur côté RootDB.
Après il y a une fonctionnalité qui n’est pas encore activée mais déjà fonctionnelle, en réalité, c’est que RootDB permet de gérer une ou plusieurs organisations. Le terme est peut-être mal choisi mais l’idée c’est que une organisation = son lot d’utilisateurs, développeurs, connecteurs, afin que tout soit bien distinct. (seul le
super-adminpeut gérer les organisations) Cela pourrait peut-être répondre au besoin, à voir.Le projet est tout frais, donc il n’y a pas d’offre de support bien établie mais oui c’est envisageable, il faut voir de quoi on parle précisément. Si t’entends par support, ajouter des fonctionnalités manquantes, oui, clairement ça peut m’intéresser. :)
En tous cas, merci pour toutes ces questions. C’est toujours intéressant d’avoir ce genre de retour, ça permet d’avoir des pistes sur les fonctionnalités à intégrer.