[Obm] Annuaire des collaborateurs et dates de naissances

[Pierre BAUDRACCO]

> ce message parle de 2 sujets assez liés :
> - 1°/ les données personnels des membres d'une organisation
> - 2°/ un champ date de naissance
>
> 1°/
>
> Chaque organisation qui utilise OBM peut avoir besoin de constituer un
> annuaire des membres qui la constitue avec des informations
> personnelles telles que :
> - nom, prénom
> - adresse e-mail
> - numéro de téléphone portable
> - date de naissance
> - titre
> - adresse géographique
> - photo
> - service
> - responsable hiérarchique
>
> Il y a 2 modules OBM qu'on peut utiliser pour cela :
> - soit le module Utilisateur.
> Inconvénients :
>    * [permissions] ne permet pas à certaines personnes de renseigner  
>  ces informations sans modifier le reste. Exemple : chez nous, on   
> veut que ce soit les administrateurs systèmes qui crée les   
> utilisateurs, mais le service administratif qui remplisse le numéro   
> de portable ou le titre.
>    * [permissions] pas de moyen de visualiser la fiche sans la modifier
>
> - soit le module Contact (en créant une société spéciale)
> Inconvénients :
>    * oblige à maintenir 2 liste des membres, car on a de toute façon  
>  besoin de remplir la liste des utilisateurs, d'autant plus que  
> cette  dernière contient déjà des champs coordonnées (adresses,  
> numéro de  téléphones). Si c'est devoir tout mettre dans la fiche  
> contact, à  quoi servent-ils ?
>    * n'est pas publié dans l'annuaire LDAP, donc pas possible de   
> l'interroger avec un client lourd de messagerie
>    * ne contient pas les champs : photo, service
>
> Au début, je pensais qu'il était plus logique d'utiliser le module   
> Utilisateur, d'autant plus que dans la configuration par défaut, il   
> apparait dans le menu "Annuaire". Pourtant une personne d'AliaSource  
>  m'a dit qu'il fallait mieux utiliser le module Contact.
> Je pense que la raison, c'est la fusion des différents modules de la  
>  version 1 (Aliamin, etc) dans OBM v2.
>
> Une solution pourrait être de :
> - retirer toutes les informations personnelles (sauf nom/prénom) du   
> module utilisateur
> - stocker ces informations dans des entrées du module Contact
> - pouvoir créer des liens depuis entre les fiches des 2 modules
> - rajouter les champs manquants
> - modifier l'automate pour qu'il aille prendre les informations dans la
> bonne table
> Ça fait pas mal de développement.
>
> Est-il possible d'avoir la vision des développeurs à long terme sur   
> cette question ?

plusieurs points :
- exporter les contacts dans une branche de l'annuaire LDAP est ou  
sera bientot possible nativement.
- sur le reste la question est vaste et en cours de reflexion avec  
certains clients ou partenaires.
il y a plusieurs pistes que tu indiques. Une autre est d'avoir un  
nouveau module 'annuaire interne', distinct de l'annuaire actuel qui  
deviendrait l'annuaire technique.
l'annuaire interne permettrait de traiter les donnees non techniques  
(coordonnees,...) et donc d'avoir des droits differents.
Les admins gereraient l'annuaire technique, la RH ou autre l'annuaire interne.
Les donnees pourraient rester dans une seule table User.
Reste les questions que chaque "client" ou "utilisateur" ne souhaite  
pas forcemment la meme chose dans la partie technique ou interne (=>  
donc peut etre besoin de choses tres parametrables => lourd)

Le lien avec contact est aussi une possibilite, pas forcemment la plus  
elegante (un contact doit avoir une societe, quid des groupes  
multi-societes,... et il ne faudrait pas demander a l'admin de creer  
les 2 fiches, d'avoir a choisir la societe..)

> 2°/
>
> Par ailleurs, dans les 2 cas, l'information qu'on n'a pas, c'est la
> date de naissance. Il serait interressant d'avoir ce champ, et une
> visualisation des prochains anniversaires dans la page d'accueil.
> Cette fonctionnalité peut paraître un peu ludique, mais nous   
> l'avions avant d'utiliser OBM, et maintenant, j'ai plusieurs   
> utilisateurs qui me demandent de trouver une solution pour l'avoir à  
>  nouveau.
>
> Je veux bien prendre en charge complétement le développement de   
> cette fonctionnalité et soumettre un patch, mais il faut rajouter le  
>  champ quelque part dans le modèle de données (table Contact ou   
> UserObm, en relation avec le point n°1), et le prévoir lors du   
> prochain changement de celui-ci, donc dans la v2.2.

Ceci est prevu pour la v2.2 car.. les PDA gerent cette notion.
les chantiers d'architecture de la 2.2 debutent la semaine prochaine  
pour les contributions ;) des que nous avons brancher la 2.1

--
Pierre Baudracco - pierre.baudracco at aliasource.fr - www.aliasource.fr
AliaSource - Groupe LINAGORA Toulouse 05 62 19 24 91 - Paris 01 58 18 68 28