• Origine : SupAnn 2020
• Nom : supannEmpProfil
• Description : attribut composite décrivant les profils détaillés d'une personne ressource
• OID : 1.3.6.1.4.1.7135.1.2.1.56
• Attribut parent : aucun
• Valuation : multivalué
• ObjectClass : supannPerson
• Obligatoire : non
• Type de donnée : chaîne de caractères (longueur maxi. 4096)
• Règles de comparaison : égalité, sous-chaîne (casse ignorée)

• Type d'usage : attribut technique de type composite
• Contexte d'utilisation : LDAP, fédération
• Unicité : non
• Visibilité : public
• Indexation recommandée : sub
• Voir aussi : supannEtablissement, eduPersonAffiliation, supannEmpCorps, supannTypeEntiteAffectation, supannEntiteAffectation, supannActivite, supannCodePopulation, supannEmpDateFin, supannExtProfil, supannEtuInscription

Chaque valeur de cet attribut composite (cf. Les attributs composites) décrit un profil de personne ressource (cf. Glossaire des termes employés), en liant entre elles des informations “élémentaires” (établissement, affiliation, activité, etc.) qui s'y rapportent.

Chaque profil ainsi décrit peut être utilisé pour contrôler l'accès à des ressources, personnaliser du contenu, etc, et ce indépendamment des éventuels autres profils de la personne.

Cet attribut ne doit contenir que des valeurs définissant des profils en cours de validité. Il peut comporter plusieurs valeurs lorsque la personne cumule plusieurs profils simultanés de type “personne ressource”.

Chaque valeur est constituée des champs suivants, dans cet ordre (de gauche à droite):

Ce qui donne la syntaxe :

[etab=<supannEtablissement>]
[affil=<eduPersonAffiliation>][corps=<supannEmpCorps>]
[typeaffect=<supannTypeEntiteAffectation>][affect=<supannEntiteAffectation>]
[activite=<supannActivite>][population=<supannCodePopulation>][datefin=<supannEmpDateFin>]

Remarques :

• Seuls les champs marqués “Usage fédération” contiennent des valeurs pertinentes pour une exploitation inter-établissements (fédération d'identités notamment). Les autres sont à usage interne.

• Le seul champ marqué “obligatoire”, le code établissement “etab”, doit être présent ; cela suppose l'existence de la valeur concernée dans l'attribut élémentaire correspondant supannEtablissement.

• Lorsqu'un profil implique plusieurs valeurs pour un attribut élémentaire correspondant à l'un des champs de cet attribut, seules les combinaisons de valeurs pertinentes pour les usages envisagés (locaux ou via la fédération) ont vocation à constituer une valeur de cet attribut. En absence de besoins particuliers et de règle spécifique au champ concerné (voir notamment les remarques ci-dessous), on appliquera la règle du “plus spécifique”: la valeur à retenir dans le composite sera celle qui caractérise le plus finement l'attribut. Par exemple lorsqu'un supannActivite est renseigné avec un emploi-type et une BAP, on retiendra l'emploi-type.

• Pour les personnels hébergés, le champ “etab” doit contenir l'établissement d'accueil et non l'établissement gestionnaire (celui-ci peut néanmoins être renseigné dans l'attribut élémentaire supannEtablissement). Si, cependant, il est utile de représenter l'établissement gestionnaire, il est possible de présenter deux valeurs de l'attribut supannEmpProfil avec les deux établissements différents.

• Le champ “affil” doit être renseigné avec l'affiliation principale du profil, qui alimente également l'attribut eduPersonPrimaryAffiliation si l'utilisateur n'a pas d'autre profil, ou si ce profil est considéré comme le principal. Dans ce but, si le champ “population” est renseigné, il est recommandé d'utiliser l'affiliation principale qui y est associée (voir: Les catégories de population). Si le profil représenté n'implique aucune valeur du eduPersonAffiliation, le champ “affil” doit être omis.

• Le champ “datefin” peut contenir une date effective ou prévisionnelle, laquelle peut être réévaluée au fil du temps. Il peut être omis si aucune date de fin de profil n'est évaluable, par exemple dans le cas d'un emploi pérenne. Il s'agit d'une date de début d'invalidité. Ce champ sera toujours positionné en fin de l'attribut composite, même en cas d'ajout futur de nouveaux champs. La date doit être dans un encodage supporté par le format generalizedTime, en UTC (suffixe Z) ou avec indication du fuseau horaire.

Soit une collègue imaginaire que nous appellerons Jeanne Dupont :

• à l'Université de Nantes ({UAI}0440984F)
• personnel BIATSS titulaire (affiliation “staff” et par conséquent “employee” et “member”, code population RGPST)
• ingénieure d'études (corps 835 dans la nomenclature BCN)
• administratrice du système d'information (BAP E, code Referens III E2A41)
• au service infrastructures de la direction du système d'informations (90082 dans la nomenclature interne des structures de l'établissement)
• ce service est un service général (S231).

dn: uid=jdupont,ou=people,dc=univ-exemple,dc=fr
supannEtablissement: {UAI}0440984F
eduPersonAffiliation: employee
eduPersonAffiliation: staff
eduPersonAffiliation: member
eduPersonPrimaryAffiliation: staff
supannTypeEntiteAffectation: {SUPANN}S231
supannEntiteAffectation: 90082
supannEntiteAffectationPrincipale: 90082
supannActivite: {BAP}E
supannActivite: {REFERENS}E2A41
supannEmpCorps: {NCORPS}835
supannCodePopulation: {SUPANN}RGPST
supannEmpProfil: [etab={UAI}0440984F][affil=staff][corps={NCORPS}835]
    [typeaffect={SUPANN}S231][affect=90082][activite={REFERENS}E2A41][population={SUPANN}RGPST]

Supposons que, par ailleurs, cette personne exerce une activité d'enseignante vacataire (corps 898) dans ce même établissement, ce qui lui amène un second profil et un jeu d'attributs qui se cumulent au premier.

À ce titre, elle exerce :

• au département informatique de l'UFR Sciences et Techniques (91387)
• qui est un département d'enseignement (S202) ;
• elle y enseigne (affiliations “teacher”, ainsi que “member” déjà présent)
• l'informatique (CNU 2700)
• avec un contrat en cours jusqu'au 31 août 2020 (heure de Paris).

dn: uid=jdupont,ou=people,dc=univ-exemple,dc=fr
supannEtablissement: {UAI}0440984F
eduPersonAffiliation: employee
eduPersonAffiliation: staff
eduPersonAffiliation: teacher
eduPersonAffiliation: member
eduPersonPrimaryAffiliation: staff
supannTypeEntiteAffectation: {SUPANN}S231
supannTypeEntiteAffectation: {SUPANN}S202
supannEntiteAffectationPrincipale: 90082
supannEntiteAffectation: 90082
supannEntiteAffectation: 91387
supannActivite: {BAP}E
supannActivite: {REFERENS}E2A41
supannActivite: {CNU}2700
supannEmpCorps: {NCORPS}835
supannEmpCorps: {NCORPS}898
supannCodePopulation: {SUPANN}RGPST
supannCodePopulation: {SUPANN}RGIE
supannEmpDateFin: 20200831220000Z
supannEmpProfil: [etab={UAI}0440984F][affil=staff][corps={NCORPS}835]
    [typeaffect={SUPANN}S231][affect=90082][activite={REFERENS}E2A41][population={SUPANN}RGPST]
supannEmpProfil: [etab={UAI}0440984F][affil=teacher][corps={NCORPS}898]
    [typeaffect={SUPANN}S202][affect=91387][activite={CNU}2700][population={SUPANN}RGIE][datefin=20200831220000Z]

Comme on peut le voir sur cet exemple, le supannEmpProfil n'est pas le produit cartésien de toutes les valeurs des attributs qui le composent, mais il regroupe les valeurs significatives en ignorant celles qui sont implicites (exemple : affiliation “staff” qui implique “member”, {REFERENS}E2A41 qui implique la BAP E) en profils cohérents. Autrement dit, on a un seul profil par activité distincte, et lorsqu'une activité peut être représentée de plusieurs manières différentes, on choisit la représentation la plus spécifique.

D'après l'exemple ci-dessus, énumération des personnels exercent une activité d'enseignant (permanent ou non) au département informatique :

(&(objectClass=supannPerson)(supannEmpProfil=*[affil=teacher]*[affect=91387]*))