@palybok
merci pour ton retour !
très intéressant !
Pour ce projet, qui est loin d’être fini, je me suis accès en premier sur le chat, puis les notions de présences, de favoris, etc …
Et je n’ai quasiment rien fait pour les appels, ce qui fait que la version actuellement en ligne n’est vraiment pas aboutie.
J’ai corrigé quelques détails déjà suite aux remarques de Sylvain, mais il me reste pas mal de chose à faire.
Je me rends compte que oui, parfois les Acl par défaut ne permette pas à un utilisateur de faire des requêtes qui pourraient être utile.
Par exemple, je voulais pouvoir lister les queues, dans les buts suivants:
- Savoir dans quelle file d’attente je suis
- Connaitre les autres personnes de la file d’attente (et retrouver leur statut sur la file)
- Paramétrer mes renvois sur une file d’attente via une recherche (et non taper son extension)
- Paramétrer mes touches de fonctions (funkeys).
Pour cela, il me faudrait à minima ajouter l’Acl
confd.queues.*.read
Mais je ne veux pas d’un projet qui demande une configuration différente de celle de base concernant les Acl.
Et là, je viens de faire en sorte que ma file d’attente soit dans un carnet d’adresse, et donc trouvable via l’API en passant par Wazo.dird.search(“default”, string).
mais cela va chercher automatiquement le statut de la personne, la file d’attente n’en ayant pas, cela bloque la réponse de l’API et je me retrouve avec l’impossibilité de retrouver le numéro d’une file d’attente.
C’est dommage de ne pas avoir le numéro du standard de disponible dans une recherche de contact.
Et cet exemple, c’est une journée de test, de lecture de code, de remise en cause de mon projet …
Je me demande si je garde ces idées et mets en place un pré-requis de modification des Acl …
Mais je suis ici uniquement pour passer le temps, m’amuser, et j’ai aussi beaucoup d’affect pour Sylvain et Wazo (que j’ai connu au moment de la bascule Xivo → wazo).
Je trouve que le projet et le suivi sont excellents !!
Et ça reste un projet open source, orienté développeurs, ce qui nous permet de modifier pas mal de chose, et faire de wazo le produit que l’on veut.
Après tout, un petit PR et je pourrais avoir l’API que je souhaite.
Concernant le repo, celui du projet est en privé.
Je préfère faire le tour du SDK et par la suite le documenter, plutôt que de proposer un projet qui a peu de chance de répondre à un cahier des charges spécifiques.
Mais j’aimerais laisser la possibilité aux gens de tester rapidement et facilement Wazo, sans avoir à coder un client afin de savoir si le produit pourrait leur convenir dans un projet futur.
J’ai pensé à faire plutôt des bouts de codes ou de projets dans ce sens.
Pour info, je suis développeur du dimanche, j’apprends à coder …
J’ai fait un projet en react native avant de commencer celui-ci qui est donc mon deuxième projet en React.
ça faisait 3 ans que je n’avais pas fait de code et je n’ai qu’une petite formation en js et php qui date de 2018.
Surtout, je n’ai aucune idée du produit final, ni dans ce que Wazo me permet de faire, ni dans ce que je désire réaliser.
En moins de 2 mois, sur ce projet, je peux dire que Wazo, avec tous les défauts de sa documentation, permet tout de même à n’importe qui de rapidement construire quelque chose de fonctionnel.
Mais plus que la partie dév, je vois aussi que la partie admin manque d’informations …
En faite, elle existe, mais elle est éparpillée dans le forum ici et là.
Cette partie là, la documentation, m’intéresse fortement, mais je me sens quasi obligé de passer par le code pour mieux comprendre, réaliser puis expliquer.
En tout cas merci pour le temps passé à m’écrire et à me lire.
C’est motivant, et de voir que des gens ont le désire de partager (même plus tard) c’est fédérateur pour une “communauté” d’utilisateurs/administrateurs.
cheers !
