Personnalisation Creme

[Creme]

Merci pour vos encouragements.

Les messages sauvegardés se trouvent ici.

[lebastidien09]

Voici une première question concernant l'utilisation de champs personnalisés.

Je voudrais créer dans les contacts un champ de choix multiples. Cela sans utiliser les « custom fields ».

Par exemple, comment créer un champ proposant des supports de communication utilisés (PC, tablette, portable, smartphone, etc.) pour lequel on pourrait choisir plusieurs éléments ?

J'ai tenté avec ManyToManyField sans succès, il n'arrive pas à créer de table spécifique.

[genglert]

Plusieurs choses à savoir :

• - Les champs ManyToManyField sont un peu particuliers dans django de par leur nature même (puisqu'ils ne correspondent pas à une colonne mais une table), et sont gérés de manière un peu différente pour certaines fonctionnalités.
  Donc vous commencez tout de suite par un cas un peu particulier malheureusement ! [/*]
  
  
• - Si vous avez utilisé contribute_to_model(), il ne gère pas (encore) les ManyToManyField (le champ est ignoré).
  
  

Comment avez vous ajouté le champs ? contribute_to_model() ou en modifiant directement le modèle Contact ?
Avez vous désactivé l'app South ('south' dans settings.INSTALLED_DJANGO_APPS ) ? Si c'est le cas, ce n'est pas une bonne idée (sauf pour coder des tests unitaires), et syncdb refuse peut-être d'ajouter la table supplémentaire car la table des Contacts existe déjà (ce qui est logique en un sens, même si pénible).
Si vous avez laissé South, avez vous généré et exécuté la migration (commandes schemamigration et migrate ; voir la doc de south: http://south.readthedocs.org/en/0.7.6/ )

[lebastidien09]

Comment fonctionne contribute_to_model() (dans les grandes lignes) ?

south est bien installé et activé (dans settings.py).

Y a-t-il un autre moyen de créer ce type de champs à sélection multiple ? Via ForeignKey ?

Le but ultime serait de pouvoir changer assez facilement (faisable par un utilisateur) les éléments de la liste, via le portail de configuration générale. J'ai réussi à faire cela grâce au ForeignKey et au fichier creme_config_register.py pour des champs à sélection unique.

Jusqu'à maintenant, j'ai modifié directement le code des modèles pour tester plus facilement mes changements.

[genglert]

Vous trouverez une utilisation de contribute_to_model() dans le fichier creme/creme_core/models/auth.py (même si cette utilisation disparaîtra lorsque nous passeront a Django1.5 - mais c'est une autre histoire - la fonction en elle-même restera). Version simplifiée :

Code :

class UserProfile(Model):
    is_team = BooleanField(verbose_name=_(u'Is a team ?'), default=False)

    class Meta:
        abstract = True

contribute_to_model(UserProfile, User)

Il suffit de créer un modèle abstrait, et ses champs seront ajoutés à la classe qu'on veuxt modifier. On peut aussi passer la liste des champs qu'on veut supprimer. Mais comme je l'ai dit dans mon précédant post, cela ne marche malheureusement pas encore avec les ManyToManyField (je n'ai pas pris le temps de me pencher sur la question).

Sinon faire un ManyToManyField vers un nouveau modèle, que vous enregistrez dans creme_config (voir la documentation de création de module dans doc/) afin que les utilisateurs puissent créer de nouveaux choix disponibles, est bien la bonne façon de faire.

Reste la création/modification de table.
- Si vous désactivez 'south', la commande syncdb est celle de base de Django : elle crée les tables qui n'existe pas encore, mais ne touche pas aux tables existantes (voir mon commentaire précédant). Du coup si vous supprimez votre base à chaque fois, vos modifications de modèle seront bien prise en compte (mais vous perdez vos données évidement).
- Si activez 'south', la commande syncdb ignorera toutes les apps ayant un répertoire 'migrations', c'est à dire la plupart des apps Creme ; vous devez alors passer par les commandes schemamigration et migrate (en autres). Je vous encourage à lire la documentation de south dont je parlais dans mon message précédant.

Mon conseil : désactiver south pendant la phase de développement et développer en Tests Driven; l'avantage est que dans les test unitaires, les changement de modèles sont pris en compte entre chaque lancement des tests (donc pas besoin de casser la base à la main à chaque fois). Puis avant la mise en production activer south, et générer les migrations afin d'être prêt pour les changements ultérieurs proprement.

[lebastidien09]

Mon code doit contenir une erreur, ça me renvoie toujours une erreur 500 lorsque je veux voir une fiche de contact ou le portail des configurations.

Je vais reprendre tout ça et vous tenir au courant.

[lebastidien09]

Voici un message d'erreur lorsque je veux utiliser South :

Code :

ValueError: South does not support on_delete with SET(function) as values.

Je modifie donc la base « à la main » : ça fonctionne, mais peut-être que pour le long terme, ça risque de tout de même causer des problèmes.

[genglert]

South nous cause aussi régulièrement des problèmes, avec des petites incompatibilités avec certaines versions de Django (j'imagine qu'il touche à des fonctionnalités internes) ; ils nous est déjà arrivé de devoir générer la migration avec une version de South et de l'exécuter avec une autre pour que cela fonctionne !

Cela dit une mise à jour de South règle nos soucis la plupart du temps.

Dans votre cas, il faut voir que le on_delete est au final peu important pour South (je ne crois que ça change de contrainte dans la table, mais je peux dire une bêtise). Aussi vous pouvez toujours mettre PROTECT à la place au moment de générer la migration, puis remettre SET, même si c'est un peu discutable comme technique je l'avoue.

Je m'étonne que vous utilisiez déjà SET, alors que nous même qui faisons du Creme à longueur de journée pour des tas d'utilisations différentes, nous ne nous en servons quasiment jamais.

[lebastidien09]

Voilà, j'ai terminé les personnalisations de Creme CRM pour mon activité. Cela fonctionne bien, y compris les champs ManyToManyFields : j'ai finalement inséré des colonnes et des tables dans ma base de données et tout est rentré dans l'ordre. Les quelques tests effectués semblent corrects.

Maintenant, je voudrais personnaliser des documents à générer à partir des données contenues dans la base. Je pensais au début me servir — copier et détourner — de « Billing » dont je ne me sers pas pour l'instant mais ça ne me paraît pas raisonnable et semble compliqué.

Je m'oriente donc dans la construction d'un nouveau module. Pensez-vous qu'il est possible de me servir de Latex pour créer ces documents et éditer des PDF ? Savez-vous où je pourrais trouver une doc traitant de l'interaction Django / Latex ? Il me faudrait mieux comprendre le mécanisme de récupération de certaines informations (via une ou plusieurs sélections de l'utilisateur) dans les Contacts et les Activités et celui de sa « traduction » en Latex. Par exemple, je voudrais créer une lettre (format papier) de convocation à une activité avec le nom du contact et de l'organisation dont il dépend et les dates, heures et lieux de cette activité, cela pour x contacts et/ou activités sélectionnés.

[genglert]

Pensez-vous qu'il est possible de me servir de Latex pour créer ces documents et éditer des PDF ?

C'est exactement ce que fait le module billing. Regardez la vue export_as_pdf() de billing (30 lignes de code pas très complexes), qui utilise le fait que les templates django peuvent générer tout type de fichier texte.