37signals, Les créateurs de Backpack et Basecamp viennent d’annoncer sur leur blog le prochain lancement de Highrise, qui ambitionne d’être à la gestion de la relation client ce que Basecamp est à la gestion de projet : une offre simple, pratique et chouette à regarder.
Vous pouvez vous inscrire ici pour être avertis en avant-première de la sortie de cette nouvelle application.
Une pierre dans le jardin de Salesforce ?
Si vous êtes comme moi, vous devez être toujours à la recherche d’icônes pour agrémenter vos applications, sites web, blog et autres. En surfant sur le web, je suis tombé sur les créations d’un développeur anglais, Mark James, qui met ses créations à la disposition de la communauté.
Ce sont plus de 1000 icônes que vous trouverez dans ses différentes collections, à l’adresse famfamfam.com.
Les possibilités de paramétrage de Mezzoteam permettent aux administrateurs de laisser libre cours à leur imagination.
Il m’a été demandé de paramétrer pour un client des fiches questions-réponses, document courant sur les chantiers. L’objectif étant de permettre à un utilisateur de poser une question, et à une ou plusieurs personnes de répondre à cette question. Vous me direz, pourquoi ne pas utiliser les forums de Mezzo ?
Tout simplement pour des raisons de confidentialité : les fils de discussions postés dans les forums sont publics, alors qu’une fiche question-réponse attend une réponse précise d’un ou de plusieurs utilisateurs donnés. De plus, il semblait pratique de prévoir que les questions (et/ou les réponses) soient agrémentées de fichiers associés. Ces deux pré-requis m’interdisaient d’utiliser le forum pour répondre à ce besoin.
Malgré ces besoins de confidentialité, il fallait que la saisie soit la plus simple possible (pas de saisie de numéro d’ordre ou autre), afin d’obtenir un fonctionnement proche de celui du forum, tout en conservant les fonctionnalités riches demandées.
Le scénario utilisateur retenu consiste à créer une famile de documents « Question », qui permettra de… poser les questions ! Une fois sa question terminée, l’émetteur signera et diffusera sa question aux personnes qui doivent répondre, et qui seront informées par courriel de la présence d’une question. La réponse se fera en clonant la question, qui devra alors être marquée comme une réponse.
Pour garder un lien logique entre question et réponse, on utilisera un « code question » qui sera commun à la question et aux réponses. Le numéro servira ensuite de discriminant entre la question et les réponses.
Ainsi, une question aura un code du type : Q-003-00, et ses réponses un code du type R-003-01 et suivants.
Pour réaliser ce paramétrage, nous allons nous appuyer fortement sur le langage de formules Mezzoscript de Mezzoteam.
Tout d’abord, nous allons créer une famille de documents non-révisable appelée « Question ». Nous allons ajouter les champs utilisateurs suivants :
TYPE, Question ou Réponse, calculé)CODEQUEST, calculé)NUMORDRE, calculé)
Il est à noter que tous les champs calculés doivent ne l’être qu’à la création du document !
Le champ Type sera basé sur la formule suivante :
@Ifs(TYPE="","Q","R")
Si le champ Type ne contient rien (nous sommes en train de créer une nouvelle question), alors on lui affecte le code « Q ». Dans le cas contraire (il contient « Q »), nous sommes en train de cloner le document (donc de créer une réponse), et nous affecterons alors le code « R ».
Le champ Code Question est un champ qui contient le numéro chronologique du « fil de discussion » ; il sera partagé par la question et les réponses. Il ne doit donc être calculé que lors de création de la question et non lors du clonage d’un document (pour créer une réponse). Sa formule, plus complexe, est la suivante :
@ReturnIf(TYPE="R",CODEQUEST);
@ReturnIf(TYPE="Q" OR TYPE="",@Format(@ChronoGetNext("QUESTION"),"000"));
On utilise ici la capacité de Mezzoscript à pouvoir enchaîner plusieurs commandes dans un script. La formule @ReturnIf permet d’évaluer l’expression qu’elle contient, puis d’arrêter toute évaluation si la condition est vérifiée.
On vérifie d’abord si le document est une réponse (TYPE="R"), et si c’est le cas, on se contente de réaffecter le code récupéré lors du clonage de la question (ou d’une des réponses…). Si ce n’est pas le cas, on calcule un nouveau code question, que l’on formatte sur trois caractères.
Mais pourquoi ne pas utiliser @Ifs ?
Pourquoi utiliser @ReturnIf alors que @Ifs aurait apparemment pu faire l’affaire ? Tout simplement parce que si nous avions écrit cela :
@Ifs(TYPE="Q" OR TYPE="",@Format(@ChronoGetNext("QUESTION"),"000"),CODEQUEST)
L’ensemble de la formule aurait été évaluée à chaque fois, et notre chrono aurait été incrémenté à chaque fois que nous aurions créé une réponse (même si le numéro affiché dans le code question aurrait été correct !).
Le champ Numéro d’ordre va nous permettre de franchir encore un cap dans l’utilisation des chronos. Nous avions vu dans un précédent article que le paramètre de la formule @ChronoGetNext permettait de repérer uniquement le chrono dans la liste de ceux utilisés dans un espace de travail. Mais comme nous sommes dans MezzoScript, nous pouvons parfaitement calculer ce paramètre, afin de le rendre dynamique.
Et c’est exactement ce que nous allons faire avec le numéro d’ordre des fiches questions-réponses. En effet, ce numéro d’ordre doit se rapporter au code question, et non pas à l’ensemble des questions posées ; ainsi il sera vu comme un « indice » du code question, avec la question portant le numéro « 00 », et les réponses commençant à « 01 ».
@ReturnIf(TYPE="Q","00");
@Format(@ChronoGetNext("QUESTION"&CODEQUEST),"00")
Sur la première ligne, nous évaluons si nous avons à faire à une question, auquel cas nous lui affectons le numéro « 00 ». Dans le cas contraire, nous construisons le code du chrono du nuéméro à partir du nom de la famille documentaire et du code question de la fiche à laquelle nous répondons.
Nous n’avons plus qu’à composer le code en choisissant les champs correspondant dans l’identifiant, puis à positionner les champs Titre et Sous-titre dans le masque, puisqu’ils sont les seuls à être saisissables.
N’oubliez pas également de gérer les droits du documents, en n’affectant aucun droit de lecture particulier lorsque le document est signé (ainsi, seuls les lecteurs du document pourront répondre).
Dans les deux premières parties de notre série sur la gestion des champs chronos, nous avons vu comment mettre en place un chrono simple. Mais dans la vie réelle, il est souvent nécessaire d’afficher autre chose qu’un simple numéro, et de mettre en forme notre chrono pour l’insérer par exemple dans un identifiant, par exemple :
CR-0001 au lieu de CR-1
Dans l’exemple ci-dessus, le numéro retourné doit être mis en forme pour y ajouter trois zéros. Heureusement, une fonction de MezzoScript permet de réaliser ce formatage.
La commande @Format permet de mettre en forme une expression qui lui est passée en paramètre, selon un chaîne décrivant un format donné. De très nombreuses chaîne de formatages sont disponibles, et nous reviendrons prochainement sur cette fonction. Pour le moment, nous l’utiliserons simplement pour mettre en forme notre chrono, de la manière suivante :
@Format(ChronoGetNext("MONTYPEDEDOC"),"0000")
Vous reconnaissez certainement le premier paramètre de la fonction Format : c’est tout simplement la fonction @ChronoGetNext, qui retourne le numéro d’ordre que nous allons mettre en forme.
Le second paramètre est une chaîne qui décrit le formatage à appliquer ; ici, cette chaîne est composée de quatre zéro, indiquant que le numéro retourné sera formaté sur quatre caractères ; par exemple le numéro 17 sera formaté en 0017.
Attention : si le numéro dépasse votre format, il sera retourné tel quel ; ainsi le numéro 97010 sera retourné en 97010.
Il vous suffit maintenant de faire varier le nombre de zéros pour donner à votre chrono le formatage désiré.
A vous de jouer !
cplusn.com vous souhaite une très bonne et très heureuse année 2007. Que tous vos projets se réalisent, personnels et professionnels !