[Obm] Droits Agenda OBM 2.1.0

Mehdi Rande mehdi.rande at aliasource.fr
Mon Oct 29 17:58:55 CET 2007


Jimmy Goudin wrote:
> Bonjour,
>
Bonjour,

> [...]
> Ce qui fait que pour effacer l'évènement d'une personne, il ne faut 
> pas forcément avoir le droit d'écriture sur l'agenda que l'on 
> visualise mais sur l'agenda de la personen qui a rzentré l'évènement. 
> Cela pose des souci de gestion de droit notamment vis à vis des 
> ressources.
> [...]
>
> Dites moi si j'ai été clair...

Oui c'est clair, et c'est un point sur lequel nous travaillons, 
cependant la règle de gestion n'est pas aussi simple.
Je vais essayé de m'expliquer aussi clairement que vous l'avez fait.
Si on reprend votre exemple des 3 utilisateurs, Ueditor, Uuser, Uadmin.
Lorsque Ueditor créé un événement sur l'agenda de  Uuser, logiquement 
Ueditor est propriétaire de l'événement. En terme métier cela signifie 
que Ueditor est l'organisateur du rendez-vous. Uuser n'est que participant.
Ainsi Uadmin ne peux pas supprimer le rendez-vous car Ueditor lui même 
ne le peux pas il a juste le choix de pouvoir refuser ce rendez-vous. 
Pour prendre un exemple de situation "réelle", prenons un chef de projet 
qui à les droits d'écriture sur l'agenda d'un technicien. Le chef de 
projet prend un rendez-vous pour le technicien chez un client.
Il est logique que le chef de projet reste propriétaire de l'événement, 
le technicien ne peux pas supprimer la mission, il peux au mieux la 
refuser (a ses risques et périls :p). De plus un autre chef de projet 
qui aurait également les droits d'écriture sur l'agenda du technicien ne 
doit pas non plus pouvoir supprimer ce rendez-vous.

Cette démarche est logique, mais ne couvre pas un cas, qui pourtant est 
courant. En effet de manière général lorsqu'une secretaire (pour 
reprendre votre second exemple) prend un rendez sur l'agenda du 
directeur, de manière général elle ne prend pas un rendez-vous avec le 
directeur elle prend un rendez-vous "à la place" du directeur. Ce qui 
signifie que en toute logique l'application devrait se comporter comme 
si c'était le directeur qui avait pris le rendez-vous et non la 
secretaire (ce qui se traduit techniquement par le fait que l'événement 
devrait appartenir au directeur et non à la secretaire).

Pour résumer nous avons 2 cas :

Comportement 1 : Le chef de projet qui prend un rendez-vous pour un 
technicien et qui doit rester propriétaire de l'événement.
Comportement 2 : La secrétaire qui prend un rendez-vous "à la place" de 
son directeur et qui doit donc céder la propriété de l'événement au 
directeur.

Actuellement OBM ne fonctionne que dans le premier mode. L'autre 
fonctionnement étant également en cours de spécification mais nous 
semble moins urgent car même si le directeur ne peux pas supprimer le 
rendez-vous il peux le refuser ce qui "fonctionnellement" pour lui 
reviens au même (le rendez-vous disparait de son emplois du temps).

La solution à laquelle nous réfléchissons (des réflexions qui sont assez 
avancées en fait :)) actuellement est de rajouter dans le formulaire de 
création un champ "Organisateur". Lorsque la secrétaire créera un 
rendez-vous, elle aura le choix de mettre en tant qu' "Organisateur" 
n'importe qu'elle personne sur laquelle elle a les droits d'écriture. 
Elle pourra donc préciser que le propriétaire de l'événement (ou 
"Organisateur") est le directeur et non elle même. Ce qui devrait régler 
tout les cas. Il y a d'autres solutions mais pour base réflexions voici 
une liste non-exhaustive des cas que nous avons imaginer avant d'arriver 
à cette solution :
Soit une secrétaire S1 ayant les droits d'écriture sur D1 et D2 et une 
secrétaire S2 ayant les droits sur D2 et D3.
- S1 pose un rendez-vous personnel sur D1 : S1 et D1 doivent pouvoir 
supprimer le rendez-vous
- S1 invite D1 à un rendez-vous de la part de D2 : Seuls S1, S2 et D2 
doivent pouvoir supprimer le rendez-vous.
- S2 invite D1, D2, et D3 à un rendez-vous de la part de D3 :  Seuls S2 
et D3 doivent pouvoir supprimer le rendez-vous.

Concernant la prise de réservation d'une salle de réunion, le 
comportement 1 me parait tout à fait logique.
En effet si une personne créer une demande réservation sur une salle, 
les personnes gérant la salle peuvent refuser la réservation, mais la 
demande de réservation en elle même continue d'exister. Seule la 
personne émettrice de la demande (ou les personnes pouvant écrire sur 
son calendrier) peuvent annuler la demande.
Si Ueditor fait une demande de réservation (automatiquement validée vu 
qu'il a les droits d'écriture sur la dite ressource), il est assez 
normal que Uadmin puisse refuser la demande, mais pas la supprimer 
complément.
A noter que dans la 2.1 la gestion des droits sur les ressources, ainsi 
que des acceptations/refus de rendez-vous et les envoies de mails à été 
grandement amélioré.

J'espère avoir été clair, en cas de question n'hésitez pas,
Cordialement,
Mehdi
>
> Cordialement,
> Goudin Jimmy
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Obm mailing list
> Obm at list.aliasource.fr
> http://www.list.aliasource.fr/mailman/listinfo/obm
>   


-- 
Mehdi Rande
Aliasource
20, rue Hermès, Parc Technologique du Canal 31520 RAMONVILLE SAINT AGNE
Téléphone : +33 (0)5 62 19 24 91



More information about the Obm mailing list