Activité
Du 14 janvier 2015 au 12 février 2015
12 février 2015
- 15:17 Development #6464 (Fermé): Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- 15:17 Bug #6459 (Fermé): optparse.OptionConflictError: option -d/--domain: conflicting option string(s): -d, --domain
- 15:17 Bug #6420 (Fermé): create_tenant fait un migrate de tous les schemas
- 15:17 Development #6398 (Fermé): les répertoires des tenants doivent avoir le même nom que le domaine
- 15:17 Bug #6388 (Fermé): compatibilité 1.7 (multitenant)
- 15:17 Bug #6340 (Fermé): Ajouter une commande deploy appellable par un worker hobo
- 15:17 Development #5878 (Fermé): Ajout de hobo et django-cmsplugin-blurp au VersionMiddleware
- 15:17 Bug #5791 (Fermé): version multitenant pour safemigrate
- 15:17 Development #5781 (Fermé): safemigrate: commande pour migrer "proprement" les apps avec une nouvelle migration initiale
- 15:17 Development #5759 (Fermé): Ajouter une commande au manage pour créer un ou des tenant(s)
- 15:17 Bug #5501 (Fermé): Gestionnaire de stockage adapté au multi-tenant
- 14:59 Development #6394 (Rejeté): Le middleware multitenant doit pouvoir sauvegarder la configuration d'un tenant en json
- ce n'est plus d'actualité, cf project:Hobo pour la gestion de tout ça
- 14:57 Bug #6491 (En cours): supprimer djommon.multitenant, déplacé dans hobo
- Rien de très méchant ; c'est principalement pour éviter le risque d'avoir encore des choses déployées avec entrouvert...
- 14:55 Bug #6491 (Fermé): supprimer djommon.multitenant, déplacé dans hobo
- multitenant déplacé dans project:hobo
11 février 2015
- 11:10 Development #6464 (Résolu (à déployer)): Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- ...
- 11:09 Development #6464: Possibilité pour le create_tenant de prendre les noms de domaine depuis stdin
- Ack
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...
- 10:09 Révision 1db4b242: tenant: do not duplicate --domain option in tenant_command (#6459)
- 10:09 Révision 6211c547: tenant: add "create super user" to example commands
- 10:09 Révision dc463f1d: tenant: fix documentation reference to the manage.py command
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:37 Révision e831c9d1: release 7.0.0
- * django 1.7 support
* store tenant by hostname on filesystem - 18:36 Révision 2ba6f6bf: multitenant: update README
- 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...
- 17:04 Révision e75d0516: multitenant: sync syncdb with upstream
- 16:49 Révision 964ebb51: multitenant: sync_schemas disabled for django 1.7
- 16:48 Révision 7dcc12d8: tenant: fix django 1.6 usage (missing __init__.py)
- 16:10 Révision 01a055c6: result of tenant.create_schema is undefined
- 16:06 Révision ad0757e7: remove useless get_tenant_by_domain command (#6398)
- 15:53 Révision c1206294: renamed create_schema to create_schemas
- 15:50 Révision c298e1d4: migrate: disable if django 1.7 (#6388)
- 14:34 Révision eaac238e: multitenant: use self.schema_name in SyncCommon (#6420)
03 février 2015
- 17:35 Révision bb762ce4: tenants in TENANT_BASE/hostname (#6398)
- 17:34 Révision 1f642209: migrate_schemas: use django 1.7 if available (#6388)
- 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.
- 19:01 Révision c1f66c77: tenant object passed to context manager.
- "deploy tenant" method should be called with three parameters
Closes #6340
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:...
- 18:50 Révision d2ffb5af: Add a generic command to deploy service tenants from hobo (#6340)
- It must be overloaded by applications.
Formats disponibles : Atom