La grosse différence est donc l’unité organisationnelle ( ou)  qui est soit « masociete » soit « client ».
On veut donc autoriser l’accès au gestionnaire d’incident ( trac) à ces deux profils.
Pour cela, dans le fichier de configuration dans /etc/apache2/sites-enabled on va utiliser l’instruction Require ldap-filter dont la doc est à  cette adresse .

Le truc est de savoir si la requête ldap va fonctionner ou pas. pour cela j’ai testé cette requete: 

ldapsearch -W -x -D « cn=moimeme,dc=masociete,dc=com » '(|(ou=masociete)(ou=client))'

qui veut dire: << cherche toutes les entrées du ldap ayant comme "ou" soit "masociete", soit "client" >> .Nickel, il me renvoie bien des entrées. Du coup, je me dis, je vais mettre ça dans mon fichier de config apache : 

Require ldap-filter (|(ou=client) (ou=masociete))

katastrof, en rechargeant apache( service apache2 reload)  , impossible de se connecter ni en tant que client , ni en tant qu’utilisateur.

Voici mon fichier de configuration: 

 ServerAdmin admin-system@masociete.com
 ServerName tickets.masociete.com
 DocumentRoot /var/www/tickets
 
  Options FollowSymLinks MultiViews
   AllowOverride AuthConfig
 
 
  Options +SymLinksIfOwnerMatch
  AllowOverride All
  Order allow,deny
  Allow from all
 
 ErrorLog /var/log/apache2/trac/error.log
 LogLevel warn
 CustomLog /var/log/apache2/trac/access.log combined
 ServerSignature On
  #set up Trac handling
  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnv /var/www/tickets
  PythonOption TracUriRoot /
  PythonPath « sys.path + [‘/var/www/tickets’] »
 
 
  AuthType Basic
  AuthName « LDAP auth »
  AuthBasicProvider ldap
  AuthLDAPUrl ldap://127.0.0.1/ou=Users,dc=masociete,dc=com?uid?sub
  AuthLDAPBindDN « cn=rechercheuser,dc=masociete,dc=com »
  AuthLDAPBindPassword XXXXXXX
  Require ldap-filter |(ou=client) (ou=masociete)
 

On avait introduit deux dimensions [TimeStart] et [TimeEnd] qui permettait de faire des filtres sur les dates de début et de fin des devis.

La formule initiale qui permet de savoir le pipe pour le mois de janvier 2011, est celle-ci :

with MEMBER Measures.x as ‘

SUM( NonEmptyCrossJoin(

OpeningPeriod([TimeStart].[Month],[TimeStart].firstchild):[TimeStart].[2011].[Q1].[January],

[TimeEnd].[2011].[Q1].[January]:Closingperiod([TimeEnd].[Month],[TimeEnd].lastchild ) )

, [Measures].[Montant] )’

Select Measures.x on 0

Le problème, maintenant est que l’on doit trouver un moyen pour faire cela pour tous les mois…

On sait que contrairement à MS OLAP, Mondrian n’implémente pas la fonction linkMember et donc ne peut pas lier les deux dimensions TimeStart et TimeEnd entre elles.

Imaginons que l’on ait d’une part la liste de tous les devis ouvert et d’autre part tous les devis fermés, on pourrait ainsi savoir pour chaque période la somme des devis qui ont été traités.

En SQL ça donne :

Imaginons que cette requete soit sauvegardée entant que vue que l’on va appeler viewPipe

Si, en SQL je veux savoir le montant total des devis ouvert jusqu’au 1er janvier 2011, je dois faire cette requête:

select sum(montant) from viewPipe where TimeKey <= '2011/01/01' and DateTypeKey = 'Ouvert'

De même, je veux savoir la somme des devis clôturés jusqu’au 1er janvier 2011, la requête est sensiblement la même :

select sum(montant) from viewPipe where TimeKey <= '2011/01/01' and DateTypeKey = 'Cloturé'

Côté MDX- Mondrian, on va donc introduire une nouvelle dimension que je vais appeler [DateType] qui va permettre de gérer ce fameux status ouvert/clôturé

La particularité de cette nouvelle dimension est qu’elle

J’ai soumis le Blog à une serial blogueuse pour qu’elle me donne son avis éclairé. But: augmenter la fréquentation.
Une chose est sûre, ce blog est destiné aux geeks, et d’ailleurs c’est devenu le sous-titre.
Le but n’est pas de fournir de l’information sur les produits et dernières évolutions, Twitter est là pour ça.
Il faut donc absolument que je l’alimente d’articles de fonds plus que de brèves Je me remets donc au boulot et vais travailler chaque semaine sur son alimentation.