Bon, les amis, ce serait sans doute pas mal de finir les "groupes
d'utilisateurs" ou "listes de diffusion"... l'interface
d'abonnement/désabonnement est fonctionnelle, le reste non. Est-ce qu'on
pourrait faire une liste des champs nécessaires et de ce qu'on met dans ce
concept ?
-- Fil
Ben je ne sais pas... Qu'est-ce qu'on met dedans, et à qui ça sert ?
(s'il faut écrire un script côté serveur de ML, ça ne va pas
servir à grand'monde)
Personnellement je n'ai aucune idée pour exploiter la chose.
Olé,
> Bon, les amis, ce serait sans doute pas mal de finir les "groupes
> d'utilisateurs" ou "listes de diffusion"... l'interface
> d'abonnement/désabonnement est fonctionnelle, le reste non. Est-ce qu'on
> pourrait faire une liste des champs nécessaires et de ce qu'on met dans ce
> concept ?
Ben je ne sais pas... Qu'est-ce qu'on met dedans, et à qui ça sert ?
(s'il faut écrire un script côté serveur de ML, ça ne va pas
servir à grand'monde)
Personnellement je n'ai aucune idée pour exploiter la chose.
Peut-être pour créer des "groupes d'utilisateurs" et leur affecter
certains droits... mais lesquels ?
Pour les ML, ce qui serait intéressant c'est de pouvoir spécifier que
telle ML peut recevoir tous les x jours un mail à partir de tel
squelette... Mais en écrivant cela je constate que ça n'a rien à voir
avec groupes.php3, et plutot avec config-contenu.php3...
Donc je m'écrase.
a+
Re,
Repères si cela peut aider.
Dans le comportement des internautes qui fréquentent les divers sites que j'anime :
- peu s'inscrivent en tant que rédacteur (de leur propre chef)
- ceux qui publient ont des comportements assez individualistes
- un des usages des groupes d'utilisateurs (classique en pédagogie) serait de pouvoir associer une ou plusieurs rubriques dédiés (non visibles par d'autres) dans la partie écrire (avec articles non publiés)
Mais on peut aussi dire le contraire, c'est à dire que des articles sur des rubriques à vocation pédagogique (sur le comment utiliser spip ou sur le sujet du site) peuvent intéresser tous les internautes.
- une autre piste tient dans les questions de "formations spécifiques" par petit groupe... En fait cela reviendrait à disposer de partie de spip "pour certains aspects" accessible via la notion de groupe ... mais dans ce cas pourquoi ne pas utiliser plusieurs spip sur le même site...
Entre le simple pour l'administrateur, comme moi, qui connaît rien à la programmation php ou autre, mais qui pige l'histoire des boucles..;
et le compliqué pour répondre aux besoins de chacun...
je vous laisse le choix
Ce n'était qu'un témoignage
Reste qu'il est toujours aussi difficile de faire travailler des gens entre eux... c'est sans doute aussi une culture de notre vieux pays.
J.Chatignoux
C'est ce que je disais pas "leur affecter certains droits"
(lecture/écriture/modif de tel ou tel élement). Le problème c'est que ça
demande de revoir une grosse partie du code de /ecrire ; par exemple ne
pas afficher les rubriques/articles/breves/mots_clefs/etc. que tel
utilisateur ou tel groupe ne doit pas voir. A mon avis c'est un truc
pour SPIP 2.0 plutôt que 1.5... Pour l'instant, l'installation de
plusieurs SPIP permet généralement de résoudre des problèmes de ce
genre.
Au fait, Fil, qu'as-tu décidé par rapport à l'API de vérification
d'accès que tu imaginais "autoriser( id_user, element)" ? [ou
autoriser(id_user, type_elt, id_elt) si on veut être plus à l'aise]
a+
C'est ce que je disais pas "leur affecter certains droits"
(lecture/écriture/modif de tel ou tel élement). Le problème c'est que ça
Ah, pour moi ces listes ne serviraient pas du tout à affecter des droits,
mais juste à s'inscrire à tel ou tel service (liste de diffusion notamment).
Mh... je vois que ça va nous emmener trop loin.
Au fait, Fil, qu'as-tu décidé par rapport à l'API de vérification
d'accès que tu imaginais "autoriser( id_user, element)" ? [ou
autoriser(id_user, type_elt, id_elt) si on veut être plus à l'aise]
Rien du tout, j'avais lancé cette idée pour que vous coordonniez vos idées,
mais en ce qui me concerne ces histoires de droits me paraissent superflues.
-- Fil
Pour l'instant, l'installation de plusieurs SPIP permet généralement
de résoudre des problèmes de ce genre.
Ce n'est pas du tout pratique pour les administrateurs et modérateurs,
et encore moins si des utilisateurs doivent avoir accès à plusieurs de
ces SPIP ...
-Nicolas
Pour ma part, les deux sites spipés dont je m'occupe etant des sites
associatifs, sans parler des droits, tout ce qui ira dans le sens d'une
gestion plus poussée des intervenants (les adherents sont des
redacteurs, des administrateurs et des membres actifs, des membres du
bureau, du CA, etc...) me semble utile.
Christian Thomas
> C'est ce que je disais pas "leur affecter certains droits"
> (lecture/écriture/modif de tel ou tel élement). Le problème c'est que ça
Ah, pour moi ces listes ne serviraient pas du tout à affecter des droits,
mais juste à s'inscrire à tel ou tel service (liste de diffusion notamment).
Mh... je vois que ça va nous emmener trop loin.
J'avais compris ton désir (le titre de la page groupe.php3 est assez
clair). Mais je suis un peu comme Antoine, je n'en pige pas totalement
l'utilité. Si un système de mailing-liste de type mailman ("tout sur le
web") ou groupe yahoo existe à coté de SPIP, pourquoi refaire une
interface sous SPIP ? Autant demander aux mecs de s'inscrire directement
via ces interfaces, non ?
En revanche, une fausse idée que j'ai eu en arrivant sur groupe.php3
mais qui est finalement intéressante : on pourrait avoir une liste de
triplets (adresses M, squelette S, temporasiteur T) qui fasse que tous
les T jours un message construit avec le squelette S soit envoyé à M.
C'est une extension du principe du squelette des nouveautés que tu as
ajouté dans 1.5.
Ca permettrait d'envoyer des mails spécifiques à telle personne/liste
(exemple : les nouvelles brèves avec le mot-clefs "biologie" aux
biologistes, ceux avec le mot clef "maths" au matheux, etc...).
Penses-tu que ça puisse être un truc intéressant pour "groupes.php3" ou
bien qu'il faille le mettre dans le menu "interactivité" de la
configuration (c'est un peu planqué à mon avis) ?
Pour groupe.php3, coté interface il faudrait d'ajouter deux champs pour
une liste donnée : un champ "tous les x jours", un champ "squelette
affecté". Puis de programmer le tout en une nuit, comme vous faites
d'habitude quoi 
> Au fait, Fil, qu'as-tu décidé par rapport à l'API de vérification
> d'accès que tu imaginais "autoriser( id_user, element)" ? (...)
Rien du tout, j'avais lancé cette idée pour que vous coordonniez vos idées,
mais en ce qui me concerne ces histoires de droits me paraissent superflues.
Moi aussi, pour l'instant. Je précise "pour l'instant" car mes chefs
adorent les cahiers des charges complétement tordus.
a+
Re,
> plusieurs SPIP...
> Ce n'est pas du tout pratique pour les administrateurs et modérateurs
Effectivement et je ne me risque pas à installer plusieurs spip sur un même domaine.
De mon point de vue, la notion de groupe n'a de sens que si elle est ouverte en termes d'usages...
Plus exactement si la partie Ecrire offre des options comme :
- ici le groupe bidule qui peut discuter entre lui... (généralisation du forum administrateur par ex)
- là le groupe qui reçoit une information qualifiée (mais c'est alors la notion de liste)
- où un groupe qui ne voit que certaines parties du site "privé"..
Dans le temps j'avais travaillé avec le logiciel 4D et la notion de groupe était très pratique... On a un peu la même facilité sur Mac OS
Mais globalement, je serais assez d'accord avec Stephane
"> Mais c'est alors dans l'organisation sociale, "hors spip", que cela doit se décider, et à priori, c'est quelque chose qu'un groupe doit être capable d'implémenter "socialement" soit meme."
En fait c'est souvent par facilité qu'un groupe se forme, ou pour "échapper" en termes de positionnement à d'autres. Nous sommes bien dans l'ordre du social.
La notion de groupe n'est peut-être qu'une facilité ou une fausse bonne idée.
A suivre
J.Chatignoux
NicolasR : le probleme c'est, dans un cadre associatif, que comme a dit
Jacques Chatignoux ci-dessous sur cette liste, et j'ai fait les exactement
les mêmes constats