1. Introduction

The ESUP WebDAV server retrieves its group hierarchy from the ESUP portail portal it is connected to. The group tree is like : local.0/local101/PAGS_COMPPERS/PAGS_PERS_UR1 where local* are local groups automatically generated when the portal database is initialized and PAGS* are PAGS groups defined by the administrator. Permissions on resources are set with regard to these groups.

As said above, local groups are automatically generated. It can be a major problem to manage permissions set on the server.

====

Imagine the following scenario :

1. Permissions are set on 2 folders :

/files/shareSpaces/jediCouncil > READ and WRITE for group /roles/uPortal/local.0/local.5/PAGS_JEDI

/files/shareSpaces/lightSaberLessons > READ and WRITE for group /roles/uPortal/local.0/local.10

Note that the first permission is set for a PAGS and the second one for a local group.

2. The portal database is re-initialized - local groups are automatically generated :

/roles/uPortal/local.0/local.5/PAGS_JEDI becomes /roles/uPortal/local.0/local.55/PAGS_JEDI

/roles/uPortal/local.0/local.10 becomes /roles/uPortal/local.0/local.100

3. The consequences are :

- The permission set on the /files/shareSpaces/jediCouncil folder becomes obsolete - in other words, people in the PAGS_JEDI group can not READ/WRITE anymore.

- The local.10 group does not contain the same people as before the re-initialization, and then, rights to READ and WRITE are given to people who are not supposed to be allowed to READ and WRITE !

====

But hoppefully, the ESUP WebDAV server contains a mapping file to map group paths to aliases.

2. The group mapping file

The ESUP WebDAV server package contains a perso/Slide/src/conf/webapp/uportalStoreGroupMapping.xml file.

Once the server is deployed, this file is in the {deploymentDirectory}/webapps/slide directory.

Let's have a look at this file :

<uPortalStoreGroupMapping>
<mapping alias="Tous les groupes de personnes" targetGroup="local.0" />
<mapping alias="Tous les groupes de personnes/Administrateurs" targetGroup="local.0/local.102"/>
<mapping alias="Tous les groupes de personnes/Anonymes" targetGroup="local.0/local.15" />
<mapping alias="Tous les groupes de personnes/Etablissement" targetGroup="local.0/local.101" />
<mapping alias="Tous les groupes de personnes/IEP" targetGroup="local.0/local.205" />
<mapping alias="Tous les groupes de personnes/ENSCR" targetGroup="local.0/local.128" />
</uPortalStoreGroupMapping>

To disable the mapping just erase the xml file or comment the <mapping> entries.

Aliases and target group paths are fully qualified names.

3. Server behavior

When the file contains at least one <mapping> entry, only the defined groups and their non mapped sub groups are visible.

Consider the following mapping file :

<uPortalStoreGroupMapping>
</uPortalStoreGroupMapping>

All the groups will be visible.

Consider the following mapping file :

<uPortalStoreGroupMapping>
<mapping alias="Tous les groupes de personnes" targetGroup="local.0" />
<mapping alias="Tous les groupes de personnes/Administrateurs" targetGroup="local.0/local.102"/>
<mapping alias="Tous les groupes de personnes/Anonymes" targetGroup="local.0/local.15" />
<mapping alias="Tous les groupes de personnes/Etablissement" targetGroup="local.0/local.101" />
<mapping alias="Tous les groupes de personnes/IEP" targetGroup="local.0/local.205" />
<mapping alias="Tous les groupes de personnes/ENSCR" targetGroup="local.0/local.128" />
</uPortalStoreGroupMapping>

The visible groups will be :

-Tous les groupes de personnes

-Administrateurs

-Anonymes

-Etablissement

-IEP

-ENSCR

Even if the local.0 group contains a local.102 group, this local.102 group (Tous les groupes de personnes/local.102) will not be visible because the mapping file defines two sub groups (Personnels and Etudiants) for local.0... and no alias for local.102. In other words, if you map at least one group, you need to map all of the groups at the same depth to make them visible.