|
|
> How should templates behave? What happens if %askme% is entered in an interface field?
|
|
|
|
|
|
**what problem does this pose if people enter %askme% and when using fill fill it with twice the same interface for exemple ?**
|
|
|
|
|
|
J’ai pas compris.
|
|
|
La question était qu’est qu’on affiche dans le template. Mais il me semble qu’on avait déjà discuté de ça la dernière fois non? De mémoire la solution choisie était d’afficher un OrderedArrayAttribute avec les différents champs.
|
|
|
|
|
|
https://gitlab.fusiondirectory.org/fusiondirectory/fd-plugins/-/wikis/meeting-trigger-2020-04-22
|
|
|
|
|
|
Merci. Donc oui la solution retenue était un OrderedArrayAttribute avec les données, et pour le CSV a priori du JSON avec les champs?
|
|
|
J’ai un bout de patch avec un début d’implémentation qui ajoute un faux OrderedArrayAttribute qui donne accès aux données des interfaces dans l’onglet. Ça devrait aussi aider pour le webservice.
|
|
|
|
|
|
> How would CSV import work? (I do not see any solution allowing CSV import to import a non-fixed number of interfaces).
|
|
|
|
|
|
with the new concept people should put the interfaces linked to the systems in their csv for import
|
|
|
|
|
|
Peux-tu donner un exemple de CSV avec les données pour les interfaces. Le CSV est pas arborescent.
|
|
|
|
|
|
**pas besoin**
|
|
|
|
|
|
**debian8;eth0;192.162.10.12;eth1;192.168.2.5**
|
|
|
|
|
|
Mais ça veut dire que le nombre de colonnes est variable, comment je propose l’assignation des colonnes dans l’interface dans un cas comme ça?
|
|
|
|
|
|
**je vois bien le probleme**
|
|
|
|
|
|
Dans 1.4-dev avant merge, on peut importer des systèmes qui ont un nombre différent d’IP:
|
|
|
debian8;192.162.10.12|192.168.2.5
|
|
|
debian9;192.162.10.13
|
|
|
|
|
|
Là il faut garder cette possibilité, plus ajouter l’association entre les IPs et les autres champs des interfaces.
|
|
|
|
|
|
Donc je voyais un truc type:
|
|
|
debian8;{ip:192.162.10.12,name:eth0}|{ip:192.168.2.5,name:eth1}
|
|
|
debian9;{ip:192.162.10.13,name:eth0}
|
|
|
|
|
|
Je sais pas si c’est très propre de mettre du JSON dans du CSV mais j’ai pas trop d’autres idées.
|
|
|
|
|
|
**non mais si c'est documente ca peut se faire c'est plus formelement du csv :)**
|
|
|
|
|
|
**ca pose la question d'eventuellement un jour passer a de l'import json**
|
|
|
|
|
|
> Same questions for webservice access, how would one access interface data and edit it?
|
|
|
|
|
|
je propose donc :
|
|
|
|
|
|
|
|
|
**on merge le code actuel et qu'on note les restrictions en cours**
|
|
|
|
|
|
**on se fait des tickets lies pour le restant des developpement ou on reste sur le meme ticket ?**
|
|
|
|
|
|
Un seul ticket c’est mieux parce que les trucs vont être liés entre eux
|
|
|
|
|
|
**les modifsimport csv aussi ?**
|
|
|
|
|
|
Je sais pas, je vais faire le webservice dans un premier temps puisqu’il peut avoir des tableaux, et j’adapterai l’import CSV à partir de là. |
|
|
\ No newline at end of file |