Activity
From 12 January 2015 to 10 February 2015
10 February 2015
- 05:45 PM Development #6467 (Rejeté): Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Je pensais que chaque application avait plus de configs à faire au niveau de @deploy_command@.
On peut ignorer ce pa... - 05:38 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- On va donc avoir dans passerelle, dans combo, dans corbo, dans etc. le même code, qui va faire un create_tenant puis ...
- 05:34 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Cette commande de base ne fait que créer le tenant(schéma + répertoire).
Ensuite chaque application (combo, passerre... - 05:11 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Mais l'idée c'était d'avoir dans python-entrouvert une commande de base, satisfaisant les besoins communs (combo, pas...
- 05:06 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- En effet, ça supprime la commande de l'application @tenant_schemas@ et laisse la possibilité à une autre application,...
- 05:02 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Il me semble que ce patch supprime la commande, ça ne me semble pas l'affaire souhaitée. Par ailleurs je ne vois pas ...
- 04:56 PM Development #6467: Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Placée dans le @__init__@, la classe peut être héritée par les commandes de deploiement des applications
- 04:54 PM Development #6467 (Rejeté): Renommer/deplacer la commande de deploiement afin de permettre à l'application de la surcharger
- Renommer la commande implementée dans le ticket #6340 pour ne pas avoir de conflit des noms des commandes des applica...
- 01:55 PM Bug #6459 (Résolu (à déployer)): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- ...
- 01:53 PM Bug #6459: optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- Ack
- 10:06 AM Bug #6459 (En cours): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- L'option -d/--domain est déjà déclarée dans InteractiveTenantOption.
- 10:05 AM Bug #6459 (Fermé): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- À l'utilisation de "tenant_command".
- 12:08 PM Development #6464 (En cours): Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- 12:04 PM Development #6464 (Fermé): Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- Pour faciliter la présence d'une commande unique (par manage.py) dans sudoers, il me semble que ce serait bien d'avoi...
06 February 2015
- 05:43 PM Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Oui, il manquait le @tenant@ dans les parametres.
Je garde le ticket ouvert jusqu'à ce qu'on décide comment un sauve...
05 February 2015
- 06:20 PM Bug #6388 (Solution déployée): compatibilité 1.7 (multitenant)
- 06:19 PM Development #6398 (Solution déployée): les répertoires des tenants doivent avoir le même nom que le domaine
- 06:18 PM Bug #6420 (Solution déployée): create_tenant fait un migrate de tous les schemas
- 06:18 PM Bug #6420 (Fermé): create_tenant fait un migrate de tous les schemas
- 02:47 PM Bug #6420 (En cours): create_tenant fait un migrate de tous les schemas
- 02:42 PM Bug #6420: create_tenant fait un migrate de tous les schemas
- avec ce patch, self.schema_name est calculé depuis le self.domain quand celui-ci est indiqué (--domain ...). Il peut ...
- 02:41 PM Bug #6420 (Fermé): create_tenant fait un migrate de tous les schemas
- lorsqu'on lance un create_tenant, un migrate_schema global est lancé. C'est dû à l'absence d'un paramètre self.schema...
03 February 2015
- 05:00 PM Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Ok, mais on est d'accord que le code est boggué ? (la variable "tenant" qui n'existe pas). Et pour moi, ça devrait pl...
- 04:52 PM Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Mon idée est que les agents de deploiements appelent cette methode en lui passant le nom(le domain plus précisement) ...
- 04:42 PM Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Je n'ai pas compris non plus.
- 04:43 PM Development #6398 (En cours): les répertoires des tenants doivent avoir le même nom que le domaine
- 04:43 PM Development #6398 (Information nécessaire): les répertoires des tenants doivent avoir le même nom que le domaine
- 04:41 PM Development #6398: les répertoires des tenants doivent avoir le même nom que le domaine
- Un patch un peu plus complet
- 11:34 AM Bug #6388 (En cours): compatibilité 1.7 (multitenant)
- Voici un patch principalement sur migrate_schemas. Il suppose que django-tenant-schema est la version master (1.5.x).
02 February 2015
- 04:35 PM Development #6398: les répertoires des tenants doivent avoir le même nom que le domaine
- A premiere vue un patch du genre devrait suffire:...
- 04:33 PM Development #6398 (Fermé): les répertoires des tenants doivent avoir le même nom que le domaine
- Afin de faciliter la configuratin des statics des tenants au niveau du serveur web(nginx) ça serait bien de nommer le...
- 10:13 AM Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Ça ajoute une fonction qui n'est pas utilisée, elle serait appelée où ?...
- 10:02 AM Development #6394 (Rejeté): Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Le middleware devrait pouvoir sauvegarder la configuration d'un tenant, au format JSON, déclarée dans hobo.
30 January 2015
- 04:23 PM Bug #6388: compatibilité 1.7 (multitenant)
- Bon, il semble que d'autres choses ont bougé dans d-t-s...
- 04:23 PM Bug #6388: compatibilité 1.7 (multitenant)
- Une tentative de Benjamin
- 03:39 PM Bug #6388 (Fermé): compatibilité 1.7 (multitenant)
- Pour la partie multitenant, il y a des nouvelles choses dans django-tenant-schema, notamment au niveau de la commande...
26 January 2015
- 07:05 PM Bug #6340 (Résolu (à déployer)): Ajouter une commande deploy appellable par un worker hobo
- Appliqué par commit commit:c1f66c779d0507890c3349c6143e165fbb5cc8a4.
- 10:04 AM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- ça roule.
- 09:46 AM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Je confirme que c'est ok, sur une lecture de django-tenant-schemas.
25 January 2015
- 09:30 PM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- J'ai l'impression que nous nous sommes un peu précipité sur ce patch: le context manager du tenant attend un objet te...
23 January 2015
- 06:50 PM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- ...
- 06:15 PM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Ack
- 06:13 PM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Ça roule.
- 06:11 PM Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Gogogo.
- 05:42 PM Bug #6340 (Fermé): Ajouter une commande deploy appellable par un worker hobo
- La commande reçoit entrée un JSON de la forme:...
Also available in: Atom