• Modifier dans settings.py : Cette solution contrevient au système associé à project_settings.py qui voudrait qu'on ne modifie pas le fichier settings.py
  
• Dupliquer CREME_OPT_CSS dans project_setting.py : Cette façon de faire a l’inconvénient de ne pas prendre en compte d'éventuels modification lors de nouvelles versions de CremeCRM.
  

• Un système de migration intégré, qui supprime le besoin d'utiliser l'app externe South ; les anciennes migrations South sont incompatibles, de nouvelles migrations doivent donc être écrites/générées. Ce point est développé plus bas.
  

• Les apps doivent avoir une classe de configuration. Ce point est développé plus bas.
  
• L'ancienne façon décrire les fichiers urls.py est obsolète. Ce point est développé plus bas.
  
• L'objet _meta de vos modèles a changé ; par exemple la méthode get_field_by_name() est obsolète, get_field() doit lui être préféré.
  
• Différents moteurs de templates peuvent être utilisés ; bien que Creme utilise toujours le même moteur (pour le moment en tout cas), cela a entraîné des changements d'API dans Django. La principale différence est que le contexte devrait être un dictionnaire classique, et non plus un RequestContext. Si vous avez défini vos propres vues, vous devriez vous en soucier.
  
• La classe Meta de vos formulaires de modèles doivent avoir un attribut 'fields' (ou bien 'exclude').
  
• Changement du fonctionnement des transactions ; en général utiliser transaction.atomic() à la place de transaction.commit_on_success()/transaction.commit_manually()/transaction.savepoint*() suffira amplement.
  
• La façon dont les tests unitaires sont organisés a changé; si vous utilisez un répertoire 'tests/', il n'y a plus besoin de tous les importer à la racine, en revanche vos noms de fichiers doivent commencer par 'test_'.
  
• La bibliothèque 'django.utils.simplejson' a été supprimée ; utilisez 'json'.
  
• La bibliothèque 'django.forms.util' a été renommée 'django.forms.utils'.
  

• La description des clés (SettinKey) était stockée en base, et donc la langue des descriptions était figée à la langue de l'installation.
  
• En fait, que les clés soient stockées en base étaient tout bonnement inutile, puisque les utilisateurs ne peuvent pas en créer de nouvelles ; seules les valeurs (SettingValue) ont besoin d'être en base.
  
• Les modèles SettinKey/SettingValue étaient dans creme_config ; or cette app se veut être une simple interface de configuration ; de plus creme_core utilisait lui-même des SettinKey/SettingValue dans son code, ce qui induisait une dépendance réciproque peu élégante (même si pas gênante en pratique)

• Les SettingKey ne sont plus des modèles ; ce sont de simples instances d'objets Python (c'est à dire non sauvegardées en base), enregistrées dans une registry.
  
• Le champ 'key' des SettingValue a été remplacé par un champ 'key_id'.
  
• De plus ils sont maintenant dans creme_core (l'un dans "models", l'autre dans "core.setting_key" .

• SettingKey n'est plus importé de creme_config.models, mais de creme.creme_core.core.setting_key
  
• La méthode statique SettingKey.create() a disparue ; on instancie notre objet simplement, que l'on stocke dans une variable globale.
  
• On utilise un ugettext_lazy() et non plus un ugettext() pour la description.

• Changez l'import a depuis creme_config.models pour creme_core.models.
  
• Vos requêtes doivent éventuellement être légèrement modifiées pour prendre en compte le champ 'key' (ForeignKey vers SettingKey) devenu 'key_id' (Charfield).

genglert a écrit :

Citation :Également, je pense qu'il est important (mais ne le prenez pas mal) de professionnaliser l'interface. Je suis en stage dans une entreprise qui cherche à remplacer Sugar CRM devenu propriétaire et cette interface trop "geek" à l'air de faire douter de la qualité de ce CRM qui est mieux que ce qu'il peut laisser penser, et c'est là qu'il y a un problème.

Je comprend par contre que vous soyez attaché à cette sympathique interface mais je préfère être honnête.

Pas de problème vous pouvez faire autant de critiques que vous le voulez ; les critiques sont importantes pour s'améliorer et nous les écoutons attentivement. Quand bien même nous penserions qu'une critique n'est pas fondée, tant que c'est fait respectueusement il n'y a pas de raison de le prendre mal. Et pour le coup votre critique est sûrement fondée.

Il faut bien voir que les motivations fondatrices de Creme étaient que les CRM libres n'étaient pas suffisamment puissants ; et que les modifier pour arriver à un résultat qui nous satisferait nous semblait plus difficile encore que de partir de zéro (à l'époque nous faisions de l'intégration de VTiger, fork de SugarCRM). Et quelques années plus tard, avec nos petits moyens, nous pensons encore avoir fait le bon choix, même si cela n'a rien de facile.

Notre principal défi technique est donc de proposer beaucoup de fonctionnalités très puissantes, tout en restant accessible au niveau de l'interface. C'est évidemment complexe (et intéressant) ; et en raison de notre petite taille, nous sommes évidemment contraint de faire des choix difficiles. Dans les première années nous nous sommes plutôt concentrés sur le fond (et il y avait déjà beaucoup à faire), ce qui se comprend au vue de nos motivations que j'ai expliquées, et malheureusement un peu au dépend de la forme.

Nous ne sommes donc ni complètement satisfaits de l'interface actuelle, ni spécialement "attachés à notre interface de geek". L'interface est ce qu'elle est, fruit d'un certain nombre de concessions (et pas forcément issue d'un volonté forte de faire comme ceci ou comme cela), et il suffit de regarder les évolutions des dernières versions pour voir que cela bouge pas mal, et qu'à présent que la plupart des grosses fonctionnalités sont là, nous pouvons consacrer plus de temps à l'interface. Et autant le thème Chantilly est volontairement fantaisiste et ne laisse pas indifférent (mais comme il plaît à plein de gens ce n'est pas un problème), autant le thème Icecream est bien plus classique et s'est bien améliorée au fil des versions.

En revanche si votre critique est sûrement fondée, elle n'est pas très constructive, dans la mesure où "professionnaliser l'interface" ne veut pas dire grand chose de bien précis. Nous travaillons déjà sur l'interface (entre autres choses, mais c'est un autre problème) ; donc soit vous pensez que les améliorations précédentes allaient dans la bonne direction, et dans ce cas c'est plus des encouragements qu'il faut donner (voire des contributions) ; soit vous pensez que cela ne va pas dans la bonne direction, mais alors il va falloir préciser vos griefs, en pointant des points précis, en envoyant des patches ou en réalisant des mockups par exemple.

Il serait triste évidemment que votre entreprise ignore Creme sans même avoir regardé ses vraies possibilités. Mais il nous est impossible de satisfaire tout le monde, et si elle ne contribue d'aucune façon a Creme (argent, code, ...), il est évident que son influence sur la direction du projet sera faible. Car si comme je l'ai dit nous écoutons les critiques, notre TODO list est déjà loin d'être vide, et c'est le temps qui nous manque, pas les idées !