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)

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 :

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é à

#{managedAccess.goDisplayFunction}

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.

Astuce
Voici un exemple d'organisation faite à l'université de Rennes 1 : Menus OPI Rennes1.pdf

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é

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.

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. Ainsi lors de la première campagne, même si le serveur n'est pas ouvert, il faut mettre votre campagne en service.

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

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 qui permettront de résoudre et envoyer dynamiquement. 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