Fonction Administrateur Delegue

Bonjour,

Version 1.2
J'ai tenté l'usage d'administrateur délégué sur un des sites que je gère

En pratique et sauf erreur de ma part :
  - Il peut créer des rédacteurs ou effacer des auteurs, attribuer ou non les fonctions de messagerie interne mais pas créer d'administrateur délégué à son tour.... -> Normal

      MAIS paradoxalement il ne peut pas attribuer de login et de mots de passe aux nouveaux rédacteurs qu'il créé ?
      Seul l'administrateur principal peut venir donner Login et mot de passe

  - Il peut lui être attribué la gestion d'une ou de plusieurs rubriques

  - Dans la gestion d'une rubrique, il peut modifier la rubrique et créer de nouvelles sous-rubriques

  - Il peut venir modifier le nom et le mail de tous types de rédacteurs et même d'un administrateur principal ? Bug ?

  - Il ne dispose pas des fonctions de configuration de Spip et de sauvegarde

___________
Surprenant le fait de ne pouvoir attribuer de login et de mot de passe aux rédacteurs qu'il créé ?
Et surprenant aussi, la possibilité de venir modifier le nom, le mail d'un administrateur principal.

Merci d'avance pour la confirmation qu'il s'agit là d'un choix de l'équipe de développement.

- Pour ma part, délégué suppose lui attribuer des possibilités d'affecter login et mot de passe (sinon c'est autant de taff pour l'administrateur principal)

- Pour la possibilité de venir modifier nom et mail d'un administrateur principal... cela peut créer des surprises dans le fonctionnement collectif ! ou plus prosaîquement être source de mauvaise manip qui peuvent priver un des administrateurs de recevoir correctement ses propres mails.

D'autre part, il peut être utile dans la liste des rubriques de pouvoir visualiser le nom des administrateurs délégués qui ont en charge la rubrique sans devoir retouner dans la liste des rédacteurs pour l'identifier.

A voir pour info ou pour une prochaine version
et merci encore à l'équipe de développement

J.Chatignoux@inforoutes.net

Salut,

Je crois qu'il faut qu'on note tout ça dans un coin...

- Pour ma part, délégué suppose lui attribuer des possibilités d'affecter login et mot de passe (sinon c'est autant de taff pour l'administrateur principal)

Problème: cela signifie alors qu'il peut aussi modifier ceux existants. Cela signifie surtout qu'il peut alors créer de véritables accès sur un site dont l'admin principal peut avoir décidé de ne pas autoriser d'inscriptions à l'espace privé sans son autorisation (i.e. pas de formulaire d'inscription sur le site public).

A priori, l'idée de base était qu'un admin à accès restreint pouvait avoir besoin de créer des "auteurs" pour signer les articles, non pour créer des accès à l'espace privé (ce qui relève de l'admin principal, ou bien est autorisé via une interface en ligne sur le site public).

- Pour la possibilité de venir modifier nom et mail d'un administrateur principal... cela peut créer des surprises dans le fonctionnement collectif ! ou plus prosaîquement être source de mauvaise manip qui peuvent priver un des administrateurs de recevoir correctement ses propres mails.

Pas très grave, mais effectivement, il peut être bon qu'un admin à accès restreint ne puisse pas modifier la fiche d'un autre administrateur.

D'autre part, il peut être utile dans la liste des rubriques de pouvoir visualiser le nom des administrateurs délégués qui ont en charge la rubrique sans devoir retouner dans la liste des rédacteurs pour l'identifier.

Le problème, c'est qu'il faut alors également indiquer les administrateurs principaux (puisque eux aussi sont "responsables" de ces rubriques). La liste peut être longue sur certains sites... Mais le principe de pouvoir afficher les "administrateurs responsables de cette rubrique" est intéressante; faut qu'on trouve une présentation élégante de cette info...

Si on va par là, il pourrait être sympa de pouvoir afficher une telle information sur le site public lui-même: "cette rubrique est gérée par...". Mais bon, ça c'est pas gagné ;-))

Amicalement,
ARNO*

--
Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.uzine.net

DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B

re,

Merdi Arno de ta réponse.

_________
Quelques compléments pour nourrir la réflexion :
  > A priori, l'idée de base était qu'un admin à accès restreint pouvait
  > avoir besoin de créer des "auteurs" pour signer les articles, non pour
  > créer des accès à l'espace privé (ce qui relève de l'admin principal, ou
  > bien est autorisé via une interface en ligne sur le site public).

  C'est un choix mais est-ce que cela signifie qu'il peut exister des
auteurs sans accès direct à l'espace "écrire" car il me semble difficile
à l'admin principal de savoir qui a été créé par l'admin délégué...
ensuite de revenir sur chaque nouvel auteur créé pour lui attribuer un
login et mot de passe...

  Il n'est même pas certain que l'admin délégué pensera à envoyer
régulièrement une liste à jour des auteurs qu'il a créé, à l'admin
principal pour création des codes d'accès.

  Le plus simple restant que l'auteur possible s'abonne directement via le
formulaire public... (mais quid pour les sites qui ne voudraient pas
utiliser ce formulaire public) ?

  D'autre part, si techniquement tu peux interdire à l'admini délégué de
venir modifier les noms et mails de l'admin principal, est-ce que cela
sous-entend que tu peux fort bien identifier qui a créé qui...?
Si Oui il serait peut-être possible de ne donner la fonction de créer
des codes d'accès à un admini délégué que pour les auteurs qu'il a lui
même créé (l'admin principal ayant bien sûr cette fonction également en
sécurit en quelque sorte) ?

_________
Il me semble que
  > site dont l'admin principal peut avoir décidé de ne pas autoriser
  > d'inscriptions à l'espace privé sans son autorisation
  Dans ce cas, c'est que l'admin veut conserver tous les leviers de
commande et il ne délègue pas.
  Je dirais enfin qu'en termes d'animation et d'impulsion de sites, il faut
que l'admin délégué puisse réagir vite et se sente pleinement
responsable de sa rubrique. Créér un rédacteur et les codes d'accès
(quant il n'y a pas de formulaire public) me semble une bonne solution ;
mais je ne fais que référence à ma pratique d'animation.

________
Enfin, je viens de vérifier sur l'admin délégué peut effectivement valider en publication tout type d'article et pas seulement ceux de sa rubrique...
  Pour moi ce choix est bon.
  Un admin délégué est certes responsable de sa rubrique mais aussi co-responsable de l'ensemble de la qualité du site. Il est bien qu'il est droit de valider à publication des articles qui ne sont pas de la rubrique dont il a la responsabilité.

________
sur le
  > Si on va par là, il pourrait être sympa de pouvoir afficher une telle
  > information sur le site public lui-même: "cette rubrique est gérée
  > par...". Mais bon, ça c'est pas gagné ;-))

  Pour moi je pense que ce serait parfaitement honnête car animer une
rubrique c'est du taff et il n'y a aucune raison de ne pas faire
connaître le ou les responsables de la rubrique

________________
Autre question
  J'ai vu passer plusieurs mails sur une certaine "instabilité" des forums
(version 1.2) au sens ou des messages disparaitraient au bout de 48h...
  Qu'en est-il réellement ?
  Et si des corrections ont été faites, faut-il retélécharger la version
1.2 dans une autre release ?

Merci à tous

J.Chatignoux@inforoutes.net
***********************
ARNO* wrote:

>
> Salut,
>
> Je crois qu'il faut qu'on note tout ça dans un coin...
>
>> - Pour ma part, délégué suppose lui attribuer des possibilités
>> d'affecter login et mot de passe (sinon c'est autant de taff pour
>> l'administrateur principal)
>
> Problème: cela signifie alors qu'il peut aussi modifier ceux existants.
> Cela signifie surtout qu'il peut alors créer de véritables accès sur un
> site dont l'admin principal peut avoir décidé de ne pas autoriser
> d'inscriptions à l'espace privé sans son autorisation (i.e. pas de
> formulaire d'inscription sur le site public).
>
> A priori, l'idée de base était qu'un admin à accès restreint pouvait
> avoir besoin de créer des "auteurs" pour signer les articles, non pour
> créer des accès à l'espace privé (ce qui relève de l'admin principal, ou
> bien est autorisé via une interface en ligne sur le site public).
>
>> - Pour la possibilité de venir modifier nom et mail d'un
>> administrateur principal... cela peut créer des surprises dans le
>> fonctionnement collectif ! ou plus prosaîquement être source de
>> mauvaise manip qui peuvent priver un des administrateurs de recevoir
>> correctement ses propres mails.
>
> Pas très grave, mais effectivement, il peut être bon qu'un admin à accès
> restreint ne puisse pas modifier la fiche d'un autre administrateur.
>
>> D'autre part, il peut être utile dans la liste des rubriques de
>> pouvoir visualiser le nom des administrateurs délégués qui ont en
>> charge la rubrique sans devoir retouner dans la liste des rédacteurs
>> pour l'identifier.
>
> Le problème, c'est qu'il faut alors également indiquer les
> administrateurs principaux (puisque eux aussi sont "responsables" de ces
> rubriques). La liste peut être longue sur certains sites... Mais le
> principe de pouvoir afficher les "administrateurs responsables de cette
> rubrique" est intéressante; faut qu'on trouve une présentation élégante
> de cette info...
>
> Si on va par là, il pourrait être sympa de pouvoir afficher une telle
> information sur le site public lui-même: "cette rubrique est gérée
> par...". Mais bon, ça c'est pas gagné ;-))
>
> Amicalement,
> ARNO*
>

At 14:43 +0100 31/10/01, Chatignoux :

________________
Autre question
J'ai vu passer plusieurs mails sur une certaine "instabilité" des
forums
(version 1.2) au sens ou des messages disparaitraient au bout de 48h...
Qu'en est-il réellement ?
Et si des corrections ont été faites, faut-il retélécharger la version
1.2 dans une autre release ?

Mais bon sang, c'est vrai ça !!! Je m'aperçois que le passage à la version
1.2 a fait disparaitre les forums (toute la table spip_forum se retrouve
vide).

Vexé, je recharge une sauvegarde récente avec les forums... bien, ça
revient mais là, une heure après, plouf, la table est à nouveau vide !

  C'est rigolo mais à la longue ça peut devenir fastidieux :wink:

  J'suis preneur d'une piste pour arrêter de jouer à cache forum.

    Amicalement,

      Olivier

Ca pourrait venir du fichier "optimiser.php3".

Est-ce que tu peux modifier le fichier:
/ecrire/index.php3

Tout à la fin de ce fichier, il y a une ligne indiquant:
include ("optimiser.php3");

Il faudrait que tu la désactives totalement, c'est-à-dire simplement en plaçant deux slashs en début de ligne, ainsi:
// include ("optimiser.php3");

Et ensuite, réessayer la manip pour voir si les forums disparaissent à nouveau.

Si c'est ça, on aura trouvé la source de tes malheurs et chercher la solution.

ARNO*

At 16:03 +0100 31/10/01, Olivier Zablocki wrote:

At 14:43 +0100 31/10/01, Chatignoux :

________________
Autre question
J'ai vu passer plusieurs mails sur une certaine "instabilité" des
forums
(version 1.2) au sens ou des messages disparaitraient au bout de 48h...
Qu'en est-il réellement ?
Et si des corrections ont été faites, faut-il retélécharger la version
1.2 dans une autre release ?

Mais bon sang, c'est vrai ça !!! Je m'aperçois que le passage à la version
1.2 a fait disparaitre les forums (toute la table spip_forum se retrouve
vide).

Vexé, je recharge une sauvegarde récente avec les forums... bien, ça
revient mais là, une heure après, plouf, la table est à nouveau vide !

C'est rigolo mais à la longue ça peut devenir fastidieux :wink:

J'suis preneur d'une piste pour arrêter de jouer à cache forum.

  Amicalement,

    Olivier

_______________________________________________
spip mailing list
spip@rezo.net
http://listes.rezo.net/mailman/listinfo/spip

--
Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.uzine.net

DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B

Olivier Zablocki, le 31/10/01 16:03, a écrit :

At 14:43 +0100 31/10/01, Chatignoux :

________________
Autre question
J'ai vu passer plusieurs mails sur une certaine "instabilité" des
forums
(version 1.2) au sens ou des messages disparaitraient au bout de 48h...
Qu'en est-il réellement ?
Et si des corrections ont été faites, faut-il retélécharger la version
1.2 dans une autre release ?

Mais bon sang, c'est vrai ça !!! Je m'aperçois que le passage à la version
1.2 a fait disparaitre les forums (toute la table spip_forum se retrouve
vide).

Vexé, je recharge une sauvegarde récente avec les forums... bien, ça
revient mais là, une heure après, plouf, la table est à nouveau vide !

C'est rigolo mais à la longue ça peut devenir fastidieux :wink:

J'suis preneur d'une piste pour arrêter de jouer à cache forum.

Amicalement,

Je confirme, plus rien dans tous les forums du site :frowning:
_________________________________________________________________
::::::::::::::: http://www.cyberpatrouille.com ::::::::::::::::
_________________________________________________________________

Idem sur les forums interne, le vide absolu.
JMi

ben chez moi ca donne un 404 ....

christophe

----- Original Message -----
From: "Jean-Michel Blondeau" <jmb@voir.net>
To: <spip@rezo.net>
Sent: Wednesday, October 31, 2001 4:54 PM
Subject: Re: [Spip] disparition forums

Olivier Zablocki, le 31/10/01 16:03, a écrit :

At 14:43 +0100 31/10/01, Chatignoux :

________________
Autre question
J'ai vu passer plusieurs mails sur une certaine "instabilité" des
forums
(version 1.2) au sens ou des messages disparaitraient au bout de 48h...
Qu'en est-il réellement ?
Et si des corrections ont été faites, faut-il retélécharger la version
1.2 dans une autre release ?

Mais bon sang, c'est vrai ça !!! Je m'aperçois que le passage à la version
1.2 a fait disparaitre les forums (toute la table spip_forum se retrouve
vide).

Vexé, je recharge une sauvegarde récente avec les forums... bien, ça
revient mais là, une heure après, plouf, la table est à nouveau vide !

C'est rigolo mais à la longue ça peut devenir fastidieux :wink:

J'suis preneur d'une piste pour arrêter de jouer à cache forum.

Amicalement,

Je confirme, plus rien dans tous les forums du site :frowning:
_________________________________________________________________
::::::::::::::: http://www.cyberpatrouille.com ::::::::::::::::
_________________________________________________________________

_______________________________________________
spip mailing list
spip@rezo.net
http://listes.rezo.net/mailman/listinfo/spip

Hello,

Parmi ceux qui ont des problèmes de forum, est-ce que quelqu'un
sachant un peu se servir de phpMyAdmin (ou autre) pourrait
envoyer la commande suivante à MySQL :

ALTER TABLE spip_forum CHANGE id_message id_message bigint NOT NULL

... et voir si ça améliore les choses ?

a+

Antoine.

Antoine Pitrou, le 31/10/01 17:24, a écrit :

Hello,

Parmi ceux qui ont des problèmes de forum, est-ce que quelqu'un
sachant un peu se servir de phpMyAdmin (ou autre) pourrait
envoyer la commande suivante à MySQL :

ALTER TABLE spip_forum CHANGE id_message id_message bigint NOT NULL

... et voir si ça améliore les choses ?

a+

C'est fait :
____________
table spip_forum a été modifié.
requête SQL:
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null
____________
mais j'ai passé sur les conseils d'Arno l'include ("optimiser.php3");
en commentaire, dois-je le remettre ?
JMi

_________________________________________________________________
::::::::::::::: http://www.cyberpatrouille.com ::::::::::::::::
_________________________________________________________________

Antoine Pitrou, le 31/10/01 17:24, a écrit :

Hello,

Parmi ceux qui ont des problèmes de forum, est-ce que quelqu'un
sachant un peu se servir de phpMyAdmin (ou autre) pourrait
envoyer la commande suivante à MySQL :

ALTER TABLE spip_forum CHANGE id_message id_message bigint NOT NULL

... et voir si ça améliore les choses ?

a+

C'est fait :
____________
table spip_forum a été modifié.
requête SQL:
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null
____________
mais j'ai passé sur les conseils d'Arno l'include ("optimiser.php3");
en commentaire, dois-je le remettre ?
JMi

_________________________________________________________________
::::::::::::::: http://www.cyberpatrouille.com ::::::::::::::::
_________________________________________________________________

At 16:28 +0100 31/10/01, ARNO*

Si c'est ça, on aura trouvé la source de tes malheurs

Merci Arno, pour l'heure j'ai testé la manoeuvre proposée :

  // include ("optimiser.php3");

Je précise pour Jean-Michel Blondeau que je n'ai pas encore touché à la table
ALTER TABLE spip_forum CHANGE id_message id_message bigint NOT NULL comme
le proposait Antoine...

Cette fois, les forums restent en place (en tout cas depuis plus d'une
heure alors qu'ils avaient très rapidement disparus auparavent).

  Si les sorcières ne mangent pas mes potirons avant demain matin
  ça devrait être bon.

    Encore merci,

      Olivier

Jean-Michel Blondeau wrote:

table spip_forum a été modifié.
requête SQL:
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null
____________
mais j'ai passé sur les conseils d'Arno l'include ("optimiser.php3");
en commentaire, dois-je le remettre ?

Heu, oui, si tu n'as pas peur :wink:

Antoine Pitrou, le 31/10/01 19:06, a écrit :

Jean-Michel Blondeau wrote:

table spip_forum a été modifié.
requête SQL:
ALTER TABLE spip_forum CHANGE id_message id_message BIGINT (21) not null
____________
mais j'ai passé sur les conseils d'Arno l'include ("optimiser.php3");
en commentaire, dois-je le remettre ?

Heu, oui, si tu n'as pas peur :wink:
_______________________________________________

c'est fait, modif de l'article ajout d'une réponse, tout semble fonctionner
normalement. On va attendre 48h pour voir si on se fait Halloween le retour
:wink:
même pas peur !
JMi

_________________________________________________________________
::::::::::::::: http://www.cyberpatrouille.com ::::::::::::::::
_________________________________________________________________