Bon alors,
en fait c'est déjà possible en ne hackant rien ... MAIS cela n'empêche absolument pas un collaborateur de virer les vrais admins. Voila ce que j'ai compris.
1. le code est dans "modules/system/admin/users/userform.php"
ligne 115 on trouve
// Groups administration addition XOOPS 2.0.9: Mith
global $xoopsUser;
$gperm_handler =& xoops_gethandler('groupperm');
//If user has admin rights on groups
if ($gperm_handler->checkRight("system_admin", XOOPS_SYSTEM_GROUP, $xoopsUser->getGroups(), 1)) {
//add group selection
$group_select = new XoopsFormSelectGroup(_US_GROUPS, 'groups', false, $groups, 5, true);
}
else {
//add empty variable
$group_select = new XoopsFormHidden('groups[]', XOOPS_GROUP_USERS);
}
Ce script gère non pas le classement (peu d'influence en ce qui nous concerne) mais le groupe de l'utilisateur (que l'on peut créer/modifier par le menu d'admin "groupes".
Celui qui n'aura pas les droits du groupe de "webmestre" (celui par défaut)mais qui aura les droits sur le système d"éditer les utilisateurs" sera bridé dans l'affectation des groupes des utilisateurs qu'il créé. Le groupe "webmestre" ne lui est pas proposé dans le menu déroulant.
Donc jusque là c'est d'enfer puisque c'est ce que je cherchais
.
MAIS bien évidemment je pousse plus loin et j'essaie de voir ce que mon sous-webmestre peut causer comme nuisance.
- j'appelle le vrai webmestre à la modification ...
Pas de pb, je change son mot de passe, pas de pb :-o , je me déconnecte et reconnecte avec le nouveau mot de passe et là :
Plus d'accès à la console d'admin, finit.
En fait, pour nuire, le plus rapide c'est de l'effacer sans le modifier, ça marche
Adios l'admin et si c'était le seul, finit le site !
BOn je poursuit mes investigations pour voir comment contrer cela
