Wikini

DiscussionsAdministrationWikiNiSolutions

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-44-222-131-239.compute-1.amazonaws.com

Propositions de solutions fonctionnelles

(les solutions techniques seront discutées ultérieurement)

Proposition 1 (restreinte aux droits d'utilisation des actions)

Voir ActionEtDroitDUtilisation.

Proposition 2 (restreinte aux problèmes de gestion des pages)

[...] on peut très bien imaginer que la gestion de cette administration soit, par défaut, déleguée a chaque utilisateur, pour, par exemple, laisser le choix au créateur d'une page de modifier ses ACL pour qu'elle soit accessible en lecture, ecriture, commentaire aux utilisateurs identifiés ou aux anonymes. On peut imaginer que l'administrateur du site definisse un comportement par défaut lors de l'initialisation d'un Wakka, chaque utilisateur pouvant ensuite modifier ce comportement, c'est ce que je préfere et c'est ce qu'il y a en place dans Wakka actuellement, mais on peut laisser le choix également à l'administrateur d'imposer ce comportement par défaut (comme les "forced preferences" de phpgroupware).
-- DavidDelon

[...] Par exemple j'ai fais une action qui permet de créer des utilisateurs mais je l'ai restreinte à mon utilisateur que j'ai nommé WikiAdmin.... il faudrait que je définisse des privilèges pour les utilisateurs...). [...] en fait il faut que j'y travaille d'avantage pour que ça soit "généralisé" et pas seulement pour mon site.
-- PatrickPaul

Proposition 3 (restreinte aux problèmes de gestion des pages)

Je trouve que vous avez déjà fait du bon travail concernant la gestion des acls ! Pour ma part je l'ai un peu modifiée pour y inclure la notion d'administrateurs fonctionnels (indiqués par le symbole '@' dans les acls) qui n'ont pas tous les droits comme on pourrait le penser (ils subissent les droits normaux des utilisateurs), mais ils ont toujours le droit de modifier les acls des pages. J'ai aussi modifié le fait que le propriétaire d'un document n'a pas systématiquement les droits d'écriture sur une page (un administrateur peut les lui retirer tout en laissant le propriétaire de la page intact), mais il a toujours le droit de modifier les acls. Je suis en train de réfléchir au fait d'ajouter un droit acl de changer les acls, qui serait réservé aux administrateurs fonctionnels exclusivement. Ce droit d'acl autoriserait le propriétaire d'une page à changer ses acl mais là aussi un administrateur fonctionnel pourrait lui retirer ce droit (ou on pourrait même ne pas le donner par défaut).
-- ProgFou



Comment sauvegarder ces données administratives ?

Actuellement ces données "administratives" sont stockées de plusieurs manières :
On pourrait conserver ces différents modes de stockage mais cette solution comporte de nombreux inconvénients :

Ne peut-on imaginer de sauvegarder au maximum ces informations fonctionnelles en base de données ? Quitte à écrire une fonction générique générant des fichiers aux bons endroits si nécessaire. L'avantage c'est qu'une simple sauvegarde de la base permet de sauvegarder l'intégralité d'un site, y compris les données administratives. On pourrait à ce titre adopter en partie les propositions que j'ai fait à propos d'un WikiSemantique? : il s'agit de créer en base une table, et une seule, où nous stockons plusieurs paramètres différents selon la logique des triplets (une partie du code est déjà prêt dans WikiniSemantiqueSolutionsTechniques).
Par exemple :
Cela permet :
-- CharlesNepote

Solutions techniques


I. Solution provisoire, simple et efficace via le fichier de configuration

Une première solution peut consister à ajouter des variables de configuration dans wakka.config.php.
On peut imaginer deux types de variables supplémentaires :
La première indiquant le nom des administrateurs.
La seconde indiquant le nom des actions qui sont réservées aux seuls admins.
On ajoute un test dans la function "Action" du noyau et le tour est joué.
Pour le test on aurait quelque chose du genre :
<?php

$array_reserved_actions = explode(";", $this->config['reserved_2_admin']);
foreach ($array_reserved_actions as $value)
{
    if ($this->action = $value)
    {
        $reserved_action = "1";
        break;
    }
}

$array_admins = explode(";", $this->config['wiki_admin']);
foreach ($array_admins as $value)
{
    if ($this->user = $value)
    {
        $admin_right = "1";
        break;
    }
}

?>


Je pense qu'on peut rejeter définitivement ce type de solution car trop binaire : il n'est pas possible de déléguer certaines fonctions d'administration à d'autres, c'est tout ou rien. -- CharlesNepote

II. Solution provisoire, simple et efficace via le fichier de configuration

On peut imaginer un solution plus riche que la précédente du type :



III. Solution provisoire, simple et efficace via le fichier de configuration

Similaire à la précédente :

Note que je ne sais pas où mettre : il devrait y avoir deux types d'action
Une solution peut consister à mettre par défaut toutes les actions dans le premier groupe, chaque action "publique" étant explicitement configurée comme étant accessible à tous. Toutes les actions sensibles étant sans configuration, donc par défaut inacessibles, sauf l'action permettant de configurer ces droits, seule accessible l'administrateur créé à l'installaion.

Me paraît plus simple que la précédente :
Je pense la mettre en oeuvre dans l'action d'annulation de vandalisme que je prépare.
-- CharlesNepote

J'aimerai bien avoir l'avis de quelques autres membres sur cette solution (les anciens comme les nouveaux). -- CharlesNepote

Ok.
[à revoir]
1. Je vais également passer la nouvelle méthode IsAllowedFor ci-dessous
2. Les actions soumises à droits feront donc l'objet de deux étapes :

if ($this->IsAllowedFor($action, $this->GetUser)) { /* traitements */ }
On aurrait donc [code non testé] :
<?php

// Test if an action is allowed for an actor (for a user, and, in the future, a group or a robot)
function IsAllowedFor($action, $actor)
{
    $allowedActors = $this->GetConfigValue($action);
    $arrayActors = explode (";", $allowedActors);
    $n = 0;
    while ($arrayActors)
    {
        if ($arrayActors[$n] == $actor) return true;
        $n++;
    }
    return false;
}

?>

AIntegrerAuCVS
Au pire, si l'on voit que ça pose problème, il sera toujours temps de virer ça : il y a peu d'impact sur WikiNi actuellement.
[je pense prendre encore un petit délai de réflexion]
-- CharlesNepote

Autres outils d'administrations

Si jamais ça intéresse quelqu'un, j'ai rapidement mis en place quelques autres actions :
-- Sergio

Une meilleure idée pour la modification des droits d'accès pourrais se présenter sous cette forme :
"restricted_actions"=>array(
 );
Il est vrai que la syntaxe correspond plus a du PHP mais a l'avantage de permettre une customisation complète des accès pour chaque action. -- MagicalTux
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]
2005-03-30 09:51:51 :: Propriétaire : CharlesNepote :: Rétro-liens :: Cartographie :: Recherche :
XHTML 1.0 valide ? :: CSS valide ? :: -- Fonctionne avec WikiNi 0.5.0 (interwiki)