Dans un premier temps, vous devez définir toutes les nomenclatures dont a besoin l'application. Vous avez une définition des toutes les fonctionnalités dans les spécifications spécifications détaillés gestionnaires

Listes des nomenclatures à définir :

• Fonctionnalités --> ensemble des fonctionnalités de l'application ;
• Profils --> groupes de gestionnaires et leurs droits d'accès ;
• Campagnes --> Les campagnes de recrutement ;
• Type de décision --> les avis menant à un type de convocation ;
• Pièces justificatives --> les pièces à fournir pour une candidature ;
• Motivations avis --> les motifs pour les avis défavorable ;
• Gestion de contenu des mails --> Tous les mails automatiques de l'application ;
• Définition des formations --> Permet d'effectuer des recherches de version étapes par type de diplômes et par mot clef (exemple ici) ;
• Configuration du nombre de vœux par CGE --> Permet de réduire le nombre de voeux qu'un candidat peut faire sur un centre de gestion.

La plupart des nomenclatures est à éditer par l'administrateur technique mais certaines peuvent revenir à l'administrateur fonctionnel si vous en avez un.

Table des matières :

Profils

Lors de la création d'un utilisateur, on lui affecte entre autre un profil.

Ces profils permettent de définir les fonctionnalités accessibles par l'utilisateur.

Pour chaque fonctionnalité, on définit 4 niveaux de droits :

• Lecture : le gestionnaire peut uniquement accéder à la fonctionnalité et visualiser le contenu apporté par celle ci. Par extension, cela signifie, pour le domaine comme pour la fonctionnalité, que l'utilisateur pourra les voir dans son menu.
• Ajouter : le gestionnaire peut utiliser les fonctions d'ajout d'éléments dans la fonctionnalité (par exemple, ajout d'un nomenclature)
• Modifier : le gestionnaire peut utiliser les fonctions de modification d'éléments dans la fonctionnalité
• Supprimer : le gestionnaire peut utiliser les fonctions de suppression d'éléments dans la fonctionnalité

Deux profils existent par défaut à la livraison de l'application, le profil Administration et le profil Membre.

Par définition le profil Administration devra être réservé au CRI mais il peut être utile d'avoir un administrateur fonctionnel pour la définition de nomenclature.

D'autres profils peuvent être créé, ceux ci sont destinés aux gestionnaires de la Scolarité Centrale.

Voici un exemple de profils tels qu'utilisés à Rennes 1 :

• Administrateur technique (profil par défaut affecté au firstAdmin) : tous les droits sur toutes les fonctionnalités ;
• Administrateur fonctionnel : tous les droits sur le paramétrages des nomenclatures de l'application exceptés pour les campagnes, les fonctionnalités et le contenu des mails. Accès restreint sur les fonctionnalités de configuration et gestion des commission ;
• Responsable de scolarité : tous les droits sur les fonctionnalités de configuration et gestion des commission, de gestion de candidatures. Accès restreint à la lecture sur les nomenclatures ;
• Gestionnaire de scolarité : profil uniquement mis en place pour gérer la réception des dossiers. Lecture uniquement sur les nomenclatures et le paramétrage des commissions. Ajout et modification sur les traitements des gestions des candidatures (Gestion des pièces manquantes, Gestion des types de traitements et Liste des candidatures)
• Membre de commission (profil par défaut pour un membre de commission s'il n'est pas définit comme utilisateur de l'application) : possibilité uniquement de consulter la liste des candidats de ses commissions et de consulter le paramétrage des commissions.

Fonctionnalités

Cette partie permet de définir et structurer les menus et fonctionnalités de l'application.

L'ensemble des domaines et fonctionnalités sont initialisés lors de l'init-data mais ils peuvent être modifiés afin de personnaliser vos menus selon les besoins des vos gestionnaires.

Définition des domaines

Le domaine est un des items constituant le menu d'accueil.

Le champs Action définit le code Java exécuté. S'il est initialisé à#

cela permet d'afficher le sous menu, sinon cela mène à la fonctionnalité définie.

Le champs Rang permet de définir l'ordre des items dans le menu.

Définition des fonctionnalités

La fonctionnalité est un des items constituant le sous menu d'un domaine.

Vous pouvez ainsi déplacer une fonctionnalité dans un autre menu en changeant le domaine.

De même, vous pouvez déplacer l'item au sein du menu en modifiant l'ordre grâce au champs Ordre.

Campagnes

La notion de campagne est utilisée à plusieurs endroits de l'application :

• Un candidat est lié à une ou des campagnes mais seulement à une en service
• Une version d'étape est liée à une ou des campagnes

Seulement une campagne peut être en service et il ne peut y avoir qu'une campagne par année universitaire. Ainsi pour la première campagne, même si le serveur n'est pas ouvert, il faut mettre votre campagne en service car la modification n'est pas possible par la suite.

Lorsque vous créez votre campagne, il faut s'assurer que l'année universitaire soit au moins en initialisation dans Apogée.

Pour faire le passage d'une campagne à une autre, il faut créer une tâche d'archivage.

Type de décision

Le type de décision est la nomenclature utilisée lors de l'émission d'un avis et se base sur une liste restreinte de type de convocation qui est définie en dur dans l'application

Il ne peut y avoir qu'un type de décision pour les types de convocation "Refusé" et "Inscription administrative" et doivent être définitifs.

Le choix du type de convocation influera sur les mails envoyés aux candidats lors d'une émission d'avis pour un type de décision.

Cette partie est à définir par l'administrateur fonctionnel si vous en avez un.

Pièces justificatives

Pour cette partie, il est aussi intéressant que ce soit un administrateur fonctionnel qui fasse le paramétrage et ainsi regrouper un maximum de pièces "Communes à toutes les VET".

Cela permet de normaliser les noms de pièces et éviter d'en avoir plusieurs signifiant la même chose mais nommées différement.

Ainsi les scolarités pourront dans les écrans dédiés rattacher un minimum de pièces spécifiques à leurs étapes.

Dans le cas contraire, si chaque scolarité édite ses propres pièces justificatives, vous vous trouverez avec un grand nombre de pièces ce qui rendra les écrans difficilement lisibles.

Motivations d'avis

Cette partie est aussi à éditer par l'administrateur fonctionnel.

Les motivations d'avis permettent lors d'une émission d'un avis défavorable de justifier la raison du refus. Lors de la saisie d'un avis défavorable, la motivation est obligatoire et peut être complétée par un commentaire saisi par le gestionnaire.

Les motivations sont génériques, par exemple "Niveau insuffisant", "Profil inadapté" ... Le champs de commentaire permet de donner par la suite l'explication détaillée.

Gestion de contenu des mails

Les contenus de mails listés sur cet écran sont initialisés lors de la tâche init-data.

Par défaut, si vous ne les éditez pas, l'application se basera sur des données par défaut saisies en dur dans l'application.

Ces mails sont des mails "dynamiques" car ils se basent sur des variables. Ainsi lorsque le mail doit être envoyé, l'application initialisera un certain nombre de données (données sur le candidat, les commissions, les voeux ...). Ces informations disponibles, l'application fera l'interprétation du contenu "dynamique" du mail et affichera les données selon ce qui a été initialisé. Voici quelques exemples simples :

${individu.sexe} : affiche après calcul la civilité du candidat.

${commissionPojo.contactCommission.codSig} : affiche après calcul le nom du signataire définit dans la commission

Il est aussi possible des listes d'éléments, par exemple une liste d'avis pour un candidat dans une commission donnée

${begin_boucle value="avis" var="av"}
    ${av.indVoeu} - Avis : ${avis.result.libelle}${av.motivationAvis}${av.commentaire}
${end_boucle}

Les variables et autres boucles ne peuvent pas être modifié car sinon elles ne seront plus interprétées par l'application. Cependant, vous êtes libres de modifier le reste du mail, principalement pour ce qui est des formulations ou des dates saisies par défaut pour les années universitaires.

Définition des formations

Cette fonctionnalité permet de définir en parallèle du paramétrage des commissions et du rattachement d'étapes à celles-ci une offre des formations proposées dans eCandidat.

Ces 2 paramétrages effectués, le candidat pourra choisir une formation sur laquelle candidater en trois étapes ?:

• choix du type de diplôme
• filtrage par mot clé
• sélection du diplôme

Une fois le diplôme sélectionné, on lui propose l'ensemble des étapes ouvertes à candidature dans l'application.

Voici l'écran de choix tel que le voit le candidat :

Des trois étapes suivies par le candidat en découle les trois étapes de la définition de la formation.

Groupe de type de diplômes

Dans cette partie, on rattache les types de diplômes issu d'Apogée à des types de diplômes qui seront propres à l'application.

Domaine de formation

Cette partie permet de définir l'ensemble des domaines de formation énumérés dans la liste des mots clé.

Dans notre exemple ci-dessus, ce serait "Sciences humaines et sociales (SHS)", "Sciences, technologies, santé (STS)" ...

Mot clé des formations

Cette partie permet de lier les 2 parties précédentes.

On va alors définir un mot clé qui sera rattaché à un domaine de formation et pour lequel on aura une liste de diplômes.

Ainsi, on pourra retrouver un diplôme par son type, puis le mot clé auquel il est rattaché. Ensuite, si une des étapes le constituant est rattaché à une commission, le candidat pourra la sélectionner.

Configuration du nombre de vœux par CGE

Par défaut, un candidat peut saisir 6 vœux par centre de gestion.

Cette fonctionnalité permet au gestionnaire de configurer ce nombre pour un centre de gestion en particulier.

Un cas d'exemple de l'usage de cette fonctionnalité est une école d'ingénieur ayant 3 filières parmi lesquelles le candidat ne doit choisir qu'une et une seule. Pour éviter le choix multiple, le gestionnaire de cette école saisira 1 vœu pour son centre de gestion.