Activité
Du 12 janvier 2015 au 10 février 2015
10 février 2015
- 17:45 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... - 17:38 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 ...
- 17:34 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... - 17:11 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...
- 17:06 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,...
- 17:02 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 ...
- 16:56 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
- 16:54 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...
- 13:55 Bug #6459 (Résolu (à déployer)): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- ...
- 13:53 Bug #6459: optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- Ack
- 10:06 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 Bug #6459 (Fermé): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- À l'utilisation de "tenant_command".
- 12:08 Development #6464 (En cours): Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- 12:04 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 février 2015
- 17:43 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 février 2015
- 18:20 Bug #6388 (Solution déployée): compatibilité 1.7 (multitenant)
- 18:19 Development #6398 (Solution déployée): les répertoires des tenants doivent avoir le même nom que le domaine
- 18:18 Bug #6420 (Solution déployée): create_tenant fait un migrate de tous les schemas
- 18:18 Bug #6420 (Fermé): create_tenant fait un migrate de tous les schemas
- 14:47 Bug #6420 (En cours): create_tenant fait un migrate de tous les schemas
- 14:42 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 ...
- 14:41 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 février 2015
- 17:00 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...
- 16:52 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) ...
- 16:42 Development #6394: Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- Je n'ai pas compris non plus.
- 16:43 Development #6398 (En cours): les répertoires des tenants doivent avoir le même nom que le domaine
- 16:43 Development #6398 (Information nécessaire): les répertoires des tenants doivent avoir le même nom que le domaine
- 16:41 Development #6398: les répertoires des tenants doivent avoir le même nom que le domaine
- Un patch un peu plus complet
- 11:34 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 février 2015
- 16:35 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:...
- 16:33 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 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 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 janvier 2015
- 16:23 Bug #6388: compatibilité 1.7 (multitenant)
- Bon, il semble que d'autres choses ont bougé dans d-t-s...
- 16:23 Bug #6388: compatibilité 1.7 (multitenant)
- Une tentative de Benjamin
- 15:39 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 janvier 2015
- 19:05 Bug #6340 (Résolu (à déployer)): Ajouter une commande deploy appellable par un worker hobo
- Appliqué par commit commit:c1f66c779d0507890c3349c6143e165fbb5cc8a4.
- 10:04 Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- ça roule.
- 09:46 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 janvier 2015
- 21:30 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 janvier 2015
- 18:50 Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- ...
- 18:15 Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Ack
- 18:13 Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Ça roule.
- 18:11 Bug #6340: Ajouter une commande deploy appellable par un worker hobo
- Gogogo.
- 17:42 Bug #6340 (Fermé): Ajouter une commande deploy appellable par un worker hobo
- La commande reçoit entrée un JSON de la forme:...
Formats disponibles : Atom