Bonjour,
Cela ressemble à une FAQ et je m’excuse par avance si c’est le cas : il semble que je n’aie pas cherché assez soigneusement 
Comment pourrais-je écrire un script pour faire la même chose que l’assistant, plutôt que de le faire via l’interface web ?
Il commencerait par quelque chose qui ressemble à la fixture Fabricate(admin) des tests de spécification. Et peut-être appelé depuis la section personnalisée du conteneur.
Merci d’avance pour votre aide !
Wizard est à moitié des paramètres du site et à moitié des appels d’API.
Pour les appels d’API, vous pouvez lire Comment faire de l’ingénierie inverse de l’API Discourse et pour les paramètres du site, suivez l’exemple ici :
Mais… peut-être que c’est là que je suis perdu : pour appeler l’API, j’ai besoin d’une clé API. Et donc d’un utilisateur administrateur… que je n’ai pas (encore). Est-il possible d’appeler l’API sans clé API ? Ou d’obtenir une clé API qui serait détachée d’un utilisateur et qui aurait des identifiants d’administrateur ?
Il semble que je doive utiliser rake:admin pour créer l’utilisateur administrateur. En réalité, je pense que l’utilisateur administrateur est déjà créé mais non approuvé, donc je devrais le modifier pour qu’il soit approuvé.
Ou peut-être que je peux créer une clé API avec api_key:create_master et l’utiliser pour créer l’utilisateur administrateur ?
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'api_key:create_master[MASTERKEY]'
ad676e7413778aaaaa5d315c35f188591ef0edb4a4d4b2d644b9247a88421cfa
Mais il semble que je ne comprenne pas tout à fait comment cette clé maître doit être utilisée, car cela ne fonctionne pas :
# curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c35f91ef0edb4a4d4b2d644b924b7a88421cfa"
{"errors":["Vous n'êtes pas autorisé à afficher la ressource demandée. Le nom d'utilisateur ou la clé API est invalide."],"error_type":"invalid_access"}
Cependant, si je crée un utilisateur administrateur :
root@forum:/var/www/discourse# RAILS_DB=secondsite rake 'admin:create'
Email: loic@dachary.org
Password:
Repeat password:
Assurance que le compte est actif !
Compte créé avec succès avec le nom d'utilisateur loic
Voulez-vous accorder les privilèges d'administrateur à ce compte ? (Y/n) Y
Votre compte dispose désormais des privilèges d'administrateur !
et que j’utilise ensuite la même clé maître en spécifiant l’utilisateur nouvellement créé, cela fonctionne :
curl -X GET "https://forum2/categories" -H "Accept: application/json" -H "Api-Key: ad676e7413778aa3a5d315c358591ef0edb4a4d4b2d644b924b7a88421cfa" -H "Api-Username: loic"
{"category_list":{"can...
et il possède les privilèges d’administrateur puisqu’il peut également accéder à /admin/site_settings/category/branding.
Que cherchez-vous exactement à accomplir ? Voulez-vous automatiser la création d’un utilisateur administrateur et la configuration de certains paramètres ?
Oui, exactement. Je souhaite créer un nouveau forum à partir de zéro et le peupler avec des utilisateurs, des catégories et des sujets, via un script qui ne nécessite aucune interaction avec un navigateur.
Peut-être simplement créer cette base de données d’abord et la restaurer dans le cadre du processus d’installation ?
Je n’ai pas de base de données : les utilisateurs, les catégories et les sujets seront créés à partir des données de mailman2.
Si vous souhaitez importer les données, faites-le simplement dans un processus distinct.
Si cela n’était qu’un coup d’essai, ce serait acceptable. Mais je veux pouvoir tester le script d’importation. Et pour que le test s’exécute, il doit d’abord créer un Discourse à partir de zéro, sans nécessiter d’intervention manuelle au milieu du test automatisé 
Pour contexte, cela fait partie du travail que j’effectue pour importer Mailman2 dans Discourse. Le test s’exécuterait via tox, qui :
En supposant une installation multisite, la création d’un utilisateur administrateur approuvé et d’une clé API administrateur peut se faire avec :
docker exec app env RAILS_DB=secondsite rake 'api_key:create_master[MYKEY]'( echo user1@example.com ; echo $pass ; echo $pass ; echo ) | docker exec -i app env RAILS_DB=secondsite rake 'admin:create'Remarque : si vous n’êtes pas sur une installation multisite, supprimez simplement env RAILS_DB=secondsite.
Ensuite, vérifiez que cela fonctionne avec :
curl -X GET https://forum2/admin/backups -H "Accept: application/json" -H "Api-Key: 886171a73dd12759b5d6c1915b0f0d4475e8b3fff3d97954b95171200b6" -H "Api-Username: user1"
[]
(merci spécial à Jay Pfaffman pour l’inspiration)
Une fois cela terminé, Discourse ne nécessite plus l’exécution de l’assistant, bien qu’il indique qu’il devrait l’être.
Je gagne une part importante de mes revenus grâce à l’importation. Je suis assez certain que ce que je décris ci-dessous correspond à la méthode utilisée par la plupart de ceux qui pratiquent régulièrement l’importation.
Voici ce que je recommande :
La tâche de migration et la configuration d’un serveur de production sont totalement différentes et ont des exigences distinctes. Généralement, la migration nécessite des éléments dont le serveur de production n’a pas besoin (bien que je pense que l’outil d’importation mailmain fasse exception).
Lancer une migration sur un serveur multisite semble particulièrement imprudent.
Merci pour le conseil, je vais suivre cette procédure. Il y a plus de 100 Go d’archives mbox, ce qui nécessitera au moins quelques tests.
À ce sujet… il semble que l’importateur mbox crée toujours une nouvelle catégorie et ne peut pas en utiliser une existante. Auriez-vous des informations à ce sujet ?
Je ne connaissais pas le sens de foolhardy : je l’apprécie et je vais le réutiliser 
C’est d’autant plus une raison pour considérer qu’une réimportation complète est une mauvaise idée. Cela risquerait de prendre plusieurs semaines. Lorsque vous relancez l’importateur, il n’importe que les nouvelles données (et je le modifie souvent pour qu’il ignore entièrement les anciennes données).
Vous pouvez probablement modifier le script pour utiliser une catégorie existante en créant un champ personnalisé de catégorie. Je recommande de commencer avec une base de données vide et de laisser le script la créer ; vous pourrez ensuite la personnaliser comme vous le souhaitez. Lors d’une nouvelle exécution du script, il continuera à l’utiliser.
Le vrai danger avec votre importation, c’est qu’il y aura probablement des différences dans les données au fil des années : ce qui fonctionne pour des données vieilles de 10 ans ne fonctionnera pas pour des données de 5 ans, et ainsi de suite. Mais peut-être aurez-vous de la chance.
Je ne sais pas si c’est un compliment
J’utilise toujours le multisite pour les importations. Cela permet à plusieurs forums de coexister : l’un que je modifie pendant que le client peut examiner l’importation sur son voisin. Et il est facile de copier une base de données pour reprendre à partir d’un certain point.
Attends… quoi !?
Eh bien, je suis resté sans voix ! Tu es pratiquement la seule personne sur la planète qui ne travaille pas pour CDCK et qui, à mon avis, en sait plus sur les imports que moi. Et si tu utilises le multisite pour les imports, alors, eh bien, je vais envisager de faire de même. En général, je lance des conteneurs séparés sur le même hôte avec Traefik devant, donc je suppose que c’est un peu la même chose, mais pas vraiment.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
