Bonjour,
Je viens de découvrir Crème, et de l'installer sur un serveur Ubuntu pour une série de tests.
Je cherche un programme de ce type pour l'adapter à une activité particulière. Le temps me manque un peu, alors je fais le tour de plusieurs solutions.
Peut-on personnaliser Crème à loisir ? Par exemple, au lieu d'avoir « société » je souhaiterais avoir « collectivité ». Est-ce possible ? Si oui, comment faire ?
Merci d'avance.
Bonsoir,
Citation :Peut-on personnaliser Crème à loisir ?
Il est difficile de répondre à une question aussi généraliste de manière simple et précise, d'autant que vous ne dîtes pas quelles sont vos compétences, ou du moins jusqu'où êtres vous prêt à aller ; par exemple est-il envisageable de modifier le programme, ou la personnalisation ne doit être faite que via une interface graphique ? Je vais néanmoins tenter de répondre au mieux.
Dans Creme, de nombreuses choses sont personnalisables via l'interface graphique : droits des utilisateurs, présence ou non (ainsi que l'emplacement) des boutons et blocs suivant les types de fiches, menu rapide etc... Une fois les grands principes assimilés (tel les relations, propriétés, les filtres...), Creme peut être utilisé dans de nombreux workflows très différents, là encore sans "mettre les mains dans le cambouis".
Il est cependant évident que selon l'ambition des personnalisations que vous envisagez, il faudra éventuellement écrire du code, ou pire modifier le code existant. Nous nous efforçons à rendre Creme le plus configurable possible, mais il est illusoire de penser pouvoir combler les désirs de tous les utilisateurs en 3 clics dans le menu de configuration. Par exemple si vous voulez un module implémentant un comportement métier précis, il faudra passer par la case 'programmation' ; c'est ce que nous faisons pour nos clients et nous nous efforçons à ce que cela soit le plus simple et rapide possible.
Donc suivant les personnalisations précises que vous souhaitez, la réponse va de "3 clics dans la configuration générale" à "il faut écrire du code".
Citation : Par exemple, au lieu d'avoir « société » je souhaiterais avoir « collectivité ». Est-ce possible ?
Alors là je peux répondre. Il y a dans la version de développement de Creme (mais pas la version stable 1.2) un petit script qui permet de récupérer les différentes apparitions d'un terme dans les traductions, afin de mettre sa propre nomenclature.
Dans le répertoire creme/, il faut lancer la commande suivante (notez que 'organisation' est le terme utilisé en anglais pour 'société'):
Code : python manage.py i18n_overload -l fr organisation Organisation
Il faut ensuite éditer le fichier nouvellement créé que la commande indique, en modifiant les phrases en français (dans notre exemple en remplaçant 'société' par 'collectivité') et en supprimant les lignes "#, fuzzy". Il ne restera alors plus qu'à compiler ces nouvelles traductions. En se plaçant dans le répertoire locale_overload/ :
Code : django-admin.py compilemessages
J'espère que la complexité de la manœuvre vous parait acceptable.
N'hésitez pas à poser d'autres questions.
Guillaume Englert
Merci beaucoup pour votre réponse. Et je comprends que vous trouviez ma question principale trop généraliste.
En fait, je dois créer ou utiliser et adapter un programme pour gérer des visites médicales. J'ai quelques connaissances en Python (pour dire vrai, je débute mais ce langage me plaît beaucoup) et en PHP. Voilà pourquoi je suis en train de tester dans un premier temps des applications existantes avant de créer un programme entier.
Je teste actuellement 3 solutions : - - Drupal seul, mais je le laisse tomber petit à petit, je pense que ce n'est pas une solution qu'on pourra soutenir ou maintenir « simplement » si un jour je change de poste ;
- - Drupal et CiviCRM, ce dernier est très complet mais pas facilement adaptable ;
- - Creme, que je découvre.
Je vais donc pousser plus mes recherches sur Creme. À commencer par ces éléments de traduction dont vous m'avez parlé.
Merci encore pour vos éclaircissements et sans doute à bientôt pour d'autres questions.
Me voici un peu plus loin dans mes tests...
Pour info, la méthode de traduction que vous m'avez indiquée pour changer certains termes fonctionne bien !
Comment le menu déroulant de gauche est-il géré ? Comment s'affiche-t-il, comment enlever ou ajouter des entrées ? etc.
Merci d'avance.
Citation :Comment le menu déroulant de gauche est-il géré ? Comment s'affiche-t-il, comment enlever ou ajouter des entrées ? etc.
Les entrées dans le menu correspondent, en gros, aux apps installées, et auxquelles vous avez accès (en terme de droits) ; l'entrée 'Ma page' étant l'exception, et 'Accueil' correspondant grosso modo au Core.
Une première méthode pour enlever des entrées est donc de ne pas installer certaines apps, en modifiant votre local_settings.py (INSTALLED_CREME_APPS). Il faut bien faire attention à n'enlever que des apps optionnelles, et respecter les indications de dépendances en commentaires à côté des noms des apps ; à noter qu'il y a peut être des dépendances non indiquées, nous allons essayer de corriger ça dans la version 1.3. Je conseillerai aussi de ne pas enlever d'apps sur une instance qui tournerait déjà, car vous pourriez avoir des types de fiches qui n'aurait plus leur code (exemple: vous avez créé une Facture, et vous désinstallez 'billing' a posteriori) ; à terme une gestion dynamique des apps, qui permettrait une désisntallation facile, serait intéressante, mais ce n'est pas à l'ordre du jour.
L'autre méthode est de jouer avec la gestion des utilisateurs/rôles. Un utilisateur non super utilisateur doit avoir un rôle, et ce rôle définit les apps auxquelles a droit cet utilisateur. Tout ceci se configure dans l'IHM, dans la 'Configuration générale' du menu. Cette méthode permet donc à différent utilisateurs d'avoir un menu différent (contrairement à la méthode précédente).
Pour l'ajout d'entrée dans le menu, la question est plus vague. Les entrées correspondent aux grandes fonctionnalités, et donc il n'y a pas forcément de sens à en rajouter sans justement ajouter de fonctionnalités (et donc coder) ; l'ajout se fait alors via le code, de manière très simple (regardez un fichier creme_core_register.py d'une app au hasard). Il serait éventuellement utile de rajouter via l'IHM des entrées associant une vue de liste à un filtre directement (sans avoir à sélectionner le filtre à chaque fois), mais ce n'est pas prévu à court terme.
Vous ne pouvez pas déplacer (sans coder évidemment) les entrées, en revanche le menu rapide vous permet, via l'IHM, de garder rapidement accessible les quelques entrées que vous utilisez le plus.
A noter que nous étudions fortement un nouveau menu, dans lequel les entrées seront regroupées par thématique plutôt que par app.
Merci beaucoup pour votre réponse. J'ai bien désactivé les modules en trop dans le settings.py
J'ai aussi bien avancé dans la découverte de Creme.
Je suis en train de tester la création d'un module, la création d'un élément complémentaire à insérer dans un module existant et la modification d'éléments existants.
Et, bien évidemment, j'ai une nouvelle question !
Par exemple, si je ne veux pas afficher le champ Skype dans le formulaire de saisie d'un contact, est-ce que le fait de commenter les lignes concernant skype dans /forms/contact.py et dans /models/contact.py ne désorganisera pas le reste du programme ? C'est un exemple, mais je me demande si le commentaire est, dans ce cas-là, la meilleure des solutions.
Encore une fois, merci d'avance.
Citation :Par exemple, si je ne veux pas afficher le champ Skype dans le formulaire de saisie d'un contact, est-ce que le fait de commenter les lignes concernant skype dans /forms/contact.py et dans /models/contact.py ne désorganisera pas le reste du programme ? C'est un exemple, mais je me demande si le commentaire est, dans ce cas-là, la meilleure des solutions.
(Désolé j'avais écrit une réponse plus complète, mais ce magnifique forum l'a perdue... et là je suis un peu fatigué)
Très bonne question. Il y a en gros 2 méthodes en effet :
- 1) Ne pas modifier le code, et injecter les modifications aux apps existantes depuis vos propres apps. Il est possible de modifier les modèles (creme_core/utils/contribute_to_model.py), hooker les formulaires (méthodes add_post_*_callback() des formulaires), surcharger les templates (répertoire creme/templates/).
- 2) Modifier le code existant (dans votre cas vous devez modifier le template affichant le champ 'skype').
La 1ère méthode est plus propre car votre code se comporte comme un simple plugin ; le jour où Creme sera packageable/packagé par votre distribution, vous pourriez utiliser cette version par exemple. En revanche elle est plus complexe à mettre en oeuvre. Si vous optez pour la 2ème méthode, je vous conseille de garder vos modifications à part, par exemple avec l'extension 'mq' de mercurial (bitbucket permet de créer des queues de patch directement).
Quelque soit la méthode choisie, la modification peut avoir des conséquences ; si le champ est requis par du code métier et que vous l'avez enlevé il va y avoir un problème (une des joies du typage dynamique  ). Heureusement il y a les tests unitaires, qui vous permettent de constater les 'dégats'. Le code de Creme est plutôt bien couvert par les tests. Dans les cas d'un champ uniquement informatif comme 'skype', les conséquences seront sans gravité ; même si un tests listant les champs attendu pourra échouer évidemment (il faut dans l'absolu corriger le test pour ne pas que l'échec en couvre d'autres).
Merci pour votre aide.
Je ne suis pas programmeur à la base mais grâce à Creme, je progresse en Python ! J'ai encore quelques réglages à faire car j'ai « appris » et — surtout — pratiqué Python3, du coup, j'ai souvent des messages d'erreur qui me rappellent à l'ordre :?
Par contre, j'ai choisi d'utiliser Creme pour mon cas.
J'ai besoin d'un dernier conseil avant de mettre définitivement mes mains dans le cambouis.
Pensez-vous qu'il vaut mieux créer des champs personnalisés via le module de configuration ou plutôt créer un fichier à part avec ces mêmes éléments complémentaires et le lier au reste du module ?
Je n'ai pas assez de recul pour savoir s'il est plus facile de réutiliser les données issues de l'une ou l'autre de ces méthodes.
J'aimerai bien utiliser Python 3, mais Django ne le gère que depuis récemment et de manière expérimentale ; de plus nous essayons d'être déployable sur Debian stable assez facilement (c'est un repère comme un autre en matière d'OS pas trop bleeding edge ), d'où le Python 2.6 demandé de base.
Citation :Par contre, j'ai choisi d'utiliser Creme pour mon cas.
J'espère que vous en serez content ; n'hésitez pas à faire des retours, y compris positifs (c'est aussi pour ça qu'on fait du libre).
Citation :Pensez-vous qu'il vaut mieux créer des champs personnalisés via le module de configuration ou plutôt créer un fichier à part avec ces mêmes éléments complémentaires et le lier au reste du module ?
Les champs personnalisés sont bien pour les personnes n'ayant pas accès à la base ; mais autant c'est une fonctionnalité pratique, autant l'implémentation ne donne pas des performances aussi bonnes qu'avec des champs standards (ils sont stockés dans d'autres tables). De plus il y a pas mal de fonctionnalités qui ne gèrent que les champs standards. Donc vous qui pouvez toucher à la base/code, évitez les custom fields je pense.
Bon week end
Tout d'abord, un petit message à part pour dire que Creme est un programme plaisant et très pratique. Le fait qu'il soit libre est aussi un avantage indéniable.
Le code est très bien documenté, on peut facilement faire des changements basiques, adapter ou personnaliser selon ses besoins ou tout simplement découvrir son architecture.
Une question toute bête avant de passer à une question plus importante... Où passent les messages sauvegardés en « brouillon » ? J'en avais écrits 2 ou 3 dont un assez long, mais je pense les avoir perdus (ça n'a plus d'importance).
|
