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 - [EMAIL PROTECTED] - www.aliasource.fr
AliaSource - Groupe LINAGORA Toulouse 05 62 19 24 91 - Paris 01 58 18 68 28
_______________________________________________
Obm mailing list
[email protected]
http://www.list.aliasource.fr/mailman/listinfo/obm
