Gestion des groupes
Problem has been recordedIssue description
J'ai fait sept installations de YACS pour des associations ou des ONG. Je travaille également avec 3 NPDS (trop limité) ; 12 spip (trop "dogmatique") ; 3 xoops (trop rigide) ; 5 plume (pas assez évolué) ; 3 typo3 (beaucoup trop usine à gaz) ; 21 dokuwiki
Je ne suis pas le webmestre de ces sites, uniquement le "techniciens", je ne m'occupe que du contenant et en aucun cas du contenu...
Maintenant j'aimerai bien refaire mon propre site qui comporte actuellement un peu plus de 700 pages. J'utilise dokuwiki et la seule chose que je lui reproche est de ne pas pouvoir générer la page d'accueil racine ou de dossier de manière automatique pour suivre le contenu... à et aussi le problème des forums, pétitions et sondage.
Je suis très intéressé à passer le tout sur YACS (ainsi qu'une quinzaine d'autres sites). Là je viens de m'y replonger depuis trois jour à plein temps... et je ne vois vraiment pas comment régler de manière facile la question des droits de lecture, écriture, gestion, ajout, suppression, modification.
Les rares chose que j'ai pu trouver ici sur le sujet sont acceptables si l'on a une dizaine d'auteurs... mais j'ai besoin de régler des droits pour plus de 300 personnes faisant parties de 17 groupes n'ayant aucun lien entre eux... certaines personnes faisant partie de plusieurs groupes.
Autre problème, la plupart des personnes doivent avoir le droit de lire juste certaines choses, dans certains cas doivent pouvoir les corriger (sans pouvoir créer de nouvelle entité).
là j'ai finis de construire l'ossature du site avec toutes les pages (sans contenu), mais je ne vois vraiment pas comment je vais pouvoir mettre en place les droits... j'en suis à me demander si la seule possibilité n'est pas de faire plusieurs site yacs sur mon espace...
Est-il prévu de mettre un jour en place un système de gestion des droits ? ou dois-je plutôt me tourner vers un autres système pour ce genre d'utilisation ?
À noter que les installations de YACS faite jusque là donne vraiment plaine satisfaction...
Avec tous mes remérciements
Comments
Moi-meme on May 18 2007Bonjour,
beau palmarès !
Il serait vraiment dommage de se passer de yacs ou d'en installer autant que vous le dites. Mais je comprends le problème, ça donne des sueurs froides à la fin la gestion des droits, je me suis aussi cassé la tête là-dessus. En supposant que vous ayez parcouru la doc à ce sujet, et qui reste à étoffer, je ne peux que vous renvoyer aux discussions qui m'ont aussi animé sur cette question :
- Affinage du droit d'édition/consultation
- Verrouiller certaines sections
- A propos des droits d'éditeur/droits de sections
- (v6.12)Article lisible par accès url direct
Dans votre démarche, j'avoue ne pas avoir assez de précision sur ce que vous voulez faire de cette gestion de droits pour vous répondre plus efficacement. Que doivent faire/voir/modifer ces groupes et les utilisateurs qui les composent ?
Cordialement
Egide on May 19 2007Merci beaucoup pour la réponse.
Il y a trois raison à la multiplicité des systèmes utilisés :
- L'époque, suivant l'ancienneté du projet, il n'y avait pas le choix actuel, et lorsque qu'un groupe connaît bien son système, il n'est pas aisé -ni forcément judicieux- d'en changer.
- Niveau des personnes qui utiliserons le système.
- But du site. Certains groupe ont besoin de fonctionnalités que seul certains systèmes proposent, je n'ai par exemple pas cité Lodel (une installation) qui est une véritable uzine mais je n'ai dans un cas précis pas trouvé mieux...
Lorsque j'ai connu YACS il y a un peu plus d'un an, j'espérai avoir trouvé le système ultime qui me permettrai de remplacer tous les autres... mais le n° 1 ci-dessus m'a empêché d'aller plus loin...
Mon besoin de gérer les droits provient du fait suivant la structure, certains textes ne doivent (souvent durant une étape de création).
Pour le site que je veux créer maintenant (mon site perso) le but est le suivant, je fais partie des commités de plusieurs associations, j'aimerais pouvoir créer un espace communautaire pour chacune d'entre elle (entre autre), mais que le tout sois regrouper dans le même site pour limiter le travail de maintenance et de gestion. Il y a par exemple le travail de rédaction de document interne "confidentiel" et les communiqués publiques...
" O Affinage du droit d'édition/consultationC'est le premier article que j'avais lu, mais cela devient difficilement applicable pour le nombre de groupe et de personne à gérer... et quid d'un droit de lecture seulement sur une partie de cette section ?
O Verrouiller certaines sections "
" A propos des droits d'éditeur/droits de sections "C'est intéressant pour le workflow, mais de nouveau, quid des droits de lecture seule pour une partie de ce contenu ?
Merci encore beaucoup pour la réponse.
Moi-meme on May 19 2007Tu butes sur les mêmes problématiques conceptuelles que moi, est-ce qu'on développe des restrictions à partir d'entité articles/sections, ou à partir des utilisateurs, ou des deux ? Est-ce qu'on peut vraiment différencier en pratique les notions de restrictions en consultation, modification, création...?
A ma connaissance (j'ai installé et torturé pas mal de cms aussi), les gestionnaires de contenus les plus avancés que je connaisse en la matière (pour le communautaire) sont phpwebgallery et yacs. Mais ce dernier souffre de quelques défauts. Je n'ai pas essayé les toutes dernières versions (je tourne encore sous 6.12) mais je crois que ça a été réglé depuis. Normalement pour une section totalement réservée (invisible même aux membres lambda) à certains privilégiés, on devrait pouvoir leur permettre soit de créer, soit de modifier, soit de consulter, mais pas forcément tout ça en même temps. Un droit ne devrait pas obligatoirement en induire un autre. Il faut que l'équipe de développement confirme mes dires...
Dans ton exemple de commités, voici ce que je ferais (compte tenu que j'ai encore la culture v6.12 hein) : pour chaque commité -> création d'une section générale. Suivie de deux sous-section dont une publique et une privée. Dans la section privée évidemment on n'y autorise que les privilégiés, dont toi et peut-être toi seul. Dans la section publique on nregistre les communiqués officiels.
Ensuite on crée une nouvelle catégorie, pas exemple "communiqués" dans laquelle on va associer tous les communiqués officiels tout commité confondus. Ca peut devenir le foutoir et indifférencier les articles dans la liste, donc on peut imaginer de ranger la liste des articles par nom de publication (et non par date de publication) et rédiger le titre de chaque communiqué selon un protocole bien précis qui ne laissera pas de doute sur l'identité du commité auquel il est lié, par exemple :
- [Commité lambda] perlinpinpin
- [Commité zeta] blablabla
- [etc] ...
Ca peut paraître tordu mais au fond ça synthétise clairement tout l'arbre de filiation des section/articles/categories. Ce n'est qu'un exemple.
Pour tout ce qui est droit de lecture, consulation etc que tu évoques à la fin, j'ai du mal à me représenter la problématique en pratique parce que besoin d'indication sur quels genre de section tu veux donner ces droits ou pas. C'est toute la vélocité de yacs, on peut réfléchir la chose au niveau des sections seulement, ou des articles, ou par rapport à une taxonomie favorisée par les catégories. Pourrais-tu donner un exemple mathématisable, par exemple en désigant ta section par A, avec sa nature et sa fonction (l'objectif visé), puis désignant chaque utilisateur potentiel par a, b, c...selon le contenu que tu veux gérer et les droits qui s'y rapporteraient ?
GnapZ on May 19 2007Lien croisé: Héritage des droits d'un éditeur d'une section parente à une section fille ....
Egide on May 21 2007" Tu butes sur les mêmes problématiques conceptuelles que moi "
On fonde un club ?? (^_^)
" est-ce qu'on développe des restrictions à partir d'entité articles/sections, ou à partir des utilisateurs, ou des deux ? "
Je déduis de mon expérience, c'est donc imparfait et limité... Mais il me semble que sur la durée, lorsque le système doit tenir plusieurs années, que les membres en sons nombreux et qu'il y a un certains tournus, les deux concepts sont utiles !!!
" Est-ce qu'on peut vraiment différencier en pratique les notions de restrictions en consultation, modification, création...? "
De nouveau, cela dépend vraiment du genre de site... Un site communautaire comme celui de yacs n'en a certainement pas besoin... Mais lorsque l'on demande, par exemple, à un consultant externe de participer à la rédaction d'un rapport, sur la structure, on veut qu'il puisse avoir un accès à tout ou partie du site, mais qu'il ne puisse rédiger qu'à un ou deux endroits précis... (ce n'est que le premier exemple qui m'est passé par l'esprit).
" A ma connaissance (j'ai installé et torturé pas mal de cms aussi), les gestionnaires de contenus les plus avancés que je connaisse en la matière (pour le communautaire) sont phpwebgallery et yacs. Mais ce dernier souffre de quelques défauts. Je n'ai pas essayé les toutes dernières versions (je tourne encore sous 6.12) mais je crois que ça a été réglé depuis. Normalement pour une section totalement réservée (invisible même aux membres lambda) à certains privilégiés, on devrait pouvoir leur permettre soit de créer, soit de modifier, soit de consulter, mais pas forcément tout ça en même temps. Un droit ne devrait pas obligatoirement en induire un autre. Il faut que l'équipe de développement confirme mes dires... "
OK, ce serait vraiment pas mal... Enfin je crois, car pour être honnête, je ne suis pas certains d'avoir bien saisi...
Au final, j'ai l'impression que la plus grande limite est celle de devoir agir directement au niveau des utilisateurs... Si un utilisateur change de fonction ou de département, il faut lui changer tout ses droits et cela peut vite devenir très compliqué... L'avantage d'avoir des groupes est de pouvoir régler les droits de manières précise au groupe, ensuite on y affilie les auteurs que l'on veut, l'opération ne prend alors que quelques secondes.
M'enfin, là je suis vraiment en profonde réflexion, je crois bien que en l'état actuel, si j'ai bien compris, il sera beaucoup plus rapide pour mois de faire des liens et des cadres vers l'actualité du site en première page que de gérer les droits de mes utilisateurs...
Dans tous les cas, un sincère et très gros merci pour les réponses et pour l'aide que j'ai déjà reçus sur ces forums, notamment lors de l'installation de quelques sites il y a déjà une année.
GnapZ on May 21 2007Egide :
Je pense que les droits on été conçus dans l'esprit communeautaire mais ne sont pas aussi fins qu'une gestion de serveur.
Pour améliorer cela, il va falloir reprendre la plupart du code ... ce qui ne signifie pas qu'il ne faut pas le faire.
Je pense qu'il est temps de se pencher sur le problème et donc de commencer par proposer des architectures de gestion basées sur les droits d'objets, de groupes et d'utilisateurs.
A vos contributions ...
Egide on May 21 2007" Pour améliorer cela, il va falloir reprendre la plupart du code ... ce qui ne signifie pas qu'il ne faut pas le faire. "
Aye aye aye... du très gros bouleau ça... l question qu'il faut alors se poser est : est-ce que les utilisateurs visés par YACS ont vraiment besoin de cela ? Car finalement je n'ai vu que peut de demande en ce sens dans les forum (en français car je ne lis pas l'anglais).
" de commencer par proposer des architectures de gestion basées sur les droits d'objets, de groupes et d'utilisateurs "
je l'ai cité plusieurs fois ci-dessus... je sais... mais c'est à mon avis le système le plus intuitif de gestion de droit que j'ai utilisé, le système de DokuWiki. Il permet pour chaque objet de définir des droits par groupe, ou par utilisateur.
" A vos contributions ... "
Je vais me charger le cvs pour entrer dans le code, mais ce n'est certainement pas moi qui vais faire quelque chose de probant... je suis un piètre analyste programmeur, et je n'ai pas retouché du php sérieusement depuis au moins sept ans...
Moi-meme on May 21 2007Si si moi j'estime que j'ai besoin d'une gestion très fine des droits. Ca fait deux sources de requête déjà...
Quant à gérer chaque section, catégorie, article, par utilisateurs, ça tu peux avec yacs. Après jouer avec les groupes, c'est déjà plus opaque.
Egide on May 21 2007" Quant à gérer chaque section, catégorie, article, par utilisateurs, ça tu peux avec yacs. Après jouer avec les groupes, c'est déjà plus opaque. "
Oui... c'est justement ce qui, à mon avis fait défaut...
Notez bien que ce n'est pas une critique que je fais à ce logiciel... que je trouve très bien... c'est juste un regret...
En fait, mon principal regret est le suivant : si une telle gestion des droits existait, je pourrais avec le temps remplacer presque tous les sites que je gère pour YACS.
Je dis avec le temps, car les utilisateurs sont parfois déjà formés/habitués à d'autre système, il faudra donc un moment pour leur faire comprendre les gains obtenus en passant à YACS.
Notez que le temps est relatif... car je les tiens peut-être bien par les cordons de la bourse... Étant donné que je fais ce travail (à par pour les sites sous typo3) à titre totalement gracieux, je peux faire pressions et leur proposer de prendre quelqu'un d'autre... (^_^)
Disons que je trouve en YACS ce que je cherche dans les cms depuis 1996-7... Certainement qu'il n'est pas parfait... qu'il ne fait pas tout... mais il allie à la fois la richesse des éléments et la facilités d'emplois...
Merci vraiment beaucoup pour ce beau et bon programme.
GnapZ on May 21 2007Que pensez-vous de:
| Droit des objets* | Détail |
|---|---|
| Lister | voir l'arboresence des titres d'objets |
| Consulter | Lister + accéder au contenant/contenu |
| Créer | Consulter + Ajouter= du contenant/contenu |
| Modifier | Créer + Editer/Dupliquer/Promouvoir/Supprimer du contenant/contenu |
| Publier | Mettre en brouillon/publier du contenant/contenu |
Le tout à assigner à des utilisateurs et/ou des groupes:
| Utilisateur | Accès au contenant/contenu |
|---|---|
| Aucun | Bannis, aucun accès |
| Visiteur | Non inscrits, consultation (zones publiques uniquement) |
| Souscripteur | Visiteur inscrit + droits de création + commentaires et votes (zones privées sur assignation) |
| Membre | Lecteur + droits de création/modification + décisions |
| Editeur | Membre + droits d'édition + publication |
| Modérateur | Editeur + modification des droits utilisateurs + assignation de groupes |
| Associé | Editeur Administrateur - Tous les droits |
Un point particulier: Un associé ne peux supprimer son propre compte. Ainsi, il y aura toujours au moins 1 associé obligatoire ce qui rend impossible de tuer le serveur.
Attention : Ceci n'est qu'une idée perso. Cela ne signifie en rien que l'équipe de développement prévoit, est en train ou va travailler sur ce projet qui peut avoir de lourdes conséquences sur la structure actuelle de Yacs.
Moi-meme on May 21 2007J'ai des noeuds au cortex, mais ça me semble une avancée notable.
Il est vrai que ça demanderait probablement une profonde retouche à yacs, mais en même temps l'aspect communautaire est le germe conceptuel de ce CMS.
Egide on May 22 2007GnapZ :
" Un associé ne peux supprimer son propre compte. Ainsi, il y aura toujours au moins 1 associé obligatoire ce qui rend impossible de tuer le serveur "
Je ne sais pas si c'est vraiment important, car il est de toute façon possible de remettre un utilisateur via phpmyadmin pour celui qui en a le mots de passe.
Mais on pourrait aussi imaginer un simple flag pour le premier utilisateur créé à l'installation pour que celui-ci ne soit pas détruit. On peut imaginer un champ spécifique, ou plus simplement (je crois) une variable pour ce(s) login dans le fichier de configuration ou sont les données de bases de donnée.
Si YACS venait à prendre cette direction, je crois bien que je vais attendre un peu avant de remettre mon système en route, je suis prêt à "betât-tester" la chose...
Tof on May 22 2007Je suis assez d'accord avec vous sur la nécessité d'une gestion de droits, mais il faudrait peut-être avant tout réfléchir à la structure de yacs.
En effet, il est composé d'entité distinctes articles, sections, catégories, utilisateurs, toutes liées entre elles par des relations de filiation ou d'associations.
Or pour la gestion des droits, j'ai lu dans vos derniers posts que vous parlez d'entité ou d'objet indifféremment de leur type.
Je pense que c'est vers cela qu'il faut s'orienter, mais qu'il faudrait peut-être en profiter pour avoir une entité unique dans yacs, quitte à ce qu'elle ait un "type d'entité" égal à section ou article ou categorie ou utilisateur.
Cela permettrait d'avoir un code simplifié, et de faire profiter à tous les types d'entité les diverses fonctions actuellement propres à un type d'entité (behaviour pour les sections, overlay pour les articles, etc...).
-----
Tof
GnapZ on May 22 2007Egide :
L'inconvénient des paramètres, c'est qu'ils ne sont pas forcément accessibles là où se trouve l'admin au moment voulu.
L'inconvénient de bloquer le premier utilisateur créé c'est qu'il est une meilleure cible d'attaque et c'est pas forcément celui-là qui restera l'associé de tête.
L'avantage de ma proposition, c'est qu'elle permet les deux cas ci-dessus tout en laissant la liberté de définir quel compte sera l'associé final s'il ne doit en rester qu'un (Highlander) ... Ca a un côté moins "rigide", non ?
GnapZ on May 22 2007Tof :
Oui, c'est là que ça se passe ! Avant d'attribuer une gestion de droits, il faut voir à quelle entité cela va s'appliquer.
C'est un chantier plus important que l'internationalisation je pense alors il va falloir y aller doucement, étape par étape ... étapes qu'il est bon de définir avant de s'occuper des droits.
Bernard on May 23 2007Egide : les groupes ont été introduits il y a fort longtemps, dès les débuts de l'informatique en fait. Dans les années 90, la mode était plutôt aux arbres NDS et autres LDAP, qui sont beaucoup plus puissants. Avec le web 2.0, l'échelle est encore supérieure, puisque l'on vise des millions d'usagers par site. D'où le besoin de mécanismes extrêmement simples mais efficaces.
YACS sait utiliser les annuaires LDAP pour l'authentification des usagers, reste donc à gérer les droits.
Alors, groupe ou pas groupe ? En réalité, d'après mon expérience personnelle (mise en place de schéma directeur informatique, déploiement de Novell NDS à grande échelle, etc.), les groupes induisent une charge d'administration additionnelle importante, alors que, le plus souvent, un groupe protège une ressource. J' ai déduit de cette observation que le plus simple était d'associer directement et visuellement les personnes à une ressource, et c'est comme cela que fonctionne YACS.
Avant YACS, on créait des ressources, des groupes, et on liait le tout. Avec YACS, on créée des ressources, c'est-à-dire des sections, et on y lie des contributeurs privilégiés, appelés éditeurs.
Même réflexion sur la distinction des droits en lecture et en écriture, qui était très courante il y a dix ans, et qui a beaucoup évolué grâce au wiki. Aujourd'hui, avoir le droit de lire c'est aussi avoir celui d'écrire. Et de toute façon, en cas de problème, on peut revenir en arrière dans les versions.
Ce que je veux dire, c'est que l'outil informatique a une propension formidable a multiplier les coûts. L'irruption du web 2.0, c'est aussi l'opportunité de réfléchir à de nouveaux modes de fonctionnement, y compris la minimalisation des coûts d'administration. De ce point de vue, l'introduction des groupes ne me parait pas encore justifiée, mais vous avez bien entendu votre mot à dire...
Bernard on May 24 2007Encore un commentaire, pour faire suite à une discussion sur le sujet des groupes aujourd'hui même. Il s'agissait d'organiser les responsabilités éditoriales sur du contenu complexe, etc.
A l'arrivée, nous avons conclus que le besoin initial d'un groupe pour gérer des ressources pouvait être implémenté à travers seulement des sections, comme suit :
- section mère, avec assignation des éditeurs autorisés
- section filles au contenu protégé
A comparer à la demande initiale :
- groupe d'assignation des éditeurs autorisés
- sections au contenu protégé
Le regroupement des sections protégées au sein d'une seule section mère est justifié par la matérialisation, pour les internautes, d'une frontière explicite entre le domaine public et le domaine privé. C'est donc une contrainte ergonomique qui, dans ce cas, permet de regrouper le contenu au lieu des usagers...
Egide on May 25 2007Bernard : Merci pour tes réponses. Pour l'instant je cogite encore et je fais des essais pour trouver ce qui me parais le plus simple et rapide...
Tof on May 25 2007Nous l'avons déjà évoqué par ailleurs, mais on pourrait au lieu d'une gestion de groupes, pouvoir ajouter plus de rôle (approbateurs, modérateurs, etc).
ceci me parait plus pertinent pour un CMS et permettrait de faciliter les workflows.
-----
Tof
Fad on May 26 2007Je ne suis pas familiarisé avec le langage PHP et ne connais pas la mécanique de YACS. Veuillez excuser d'avance les éventuelles coquilles dans les souhaits suivants :
1. Section ou Section-Groupe.
Pourrait-on penser une sorte d’émulation de notion de groupe sans modifier la mécanique qui est déjà en place.
Comme l’écrit Bernard plus haut, « avec YACS, on créée des ressources, c'est-à-dire des sections, et on y lie des contributeurs … ». Voilà déjà un groupe ! Disons que ce sont les commerciaux. Une autre section, d’autres contributeurs, voilà un autre groupe. C’est le SAV.
Et si pour un projet donné, on voudrait faire participer les 2 groupes. Actuellement il faudrait créer une section pour ce projet et ensuite sélectionner les profils un à un. Serait-il possible d’ajouter une routine du même type que celle qui sert à sélectionner un profil pour le lier à une section, mais, qui lierai à la section courante une autre section existante, et donc, les profils qui y sont liés.
2. Contributions au sein d’une section restreinte :
Je comprends le besoin de beaucoup de gérer les droits d’une section restreinte de la même façon que pour une section non restreinte.
- Un utilisateur authentifié «inscrit » à une section restreinte pourrait contribuer de la même façon que pour une section non restreinte.
- Un éditeur d’une section restreinte pourrait contribuer de la même façon que pour une section non restreinte.
Je vois plusieurs points positifs à cela :
- Protéger l’existant d’une section restreinte d’une/de mauvaise(s) manipulation(s).
- Rassurer les contributeurs en ne leur donnant pas de droits sur les contributions des autres.
- Récupérer le temps passé à vérifier les erreurs éventuelles des contributeurs/éditeurs.
- Eviter une ingurgitation massive de Malox pour l’éditeur réel de la section
3. Et ze cerise sur ze gâteau :
En m’inspirant de la liste de GnapZ, y intégrer aussi les restrictions de visibilité :
|
Aucun |
[visibilitybanished] |
Bannis, aucun accès |
|
Visiteur |
[anonymous] |
Non inscrits, consultation (zones publiques uniquement) |
|
Souscripteur |
[visibilitysubscriber] |
Visiteur inscrit + droits de création + commentaires et votes (zones privées sur assignation) |
|
Membre |
[restricted] |
Lecteur + droits de création/modification + décisions |
|
Editeur |
[visibilityeditor] |
Membre + droits d'édition + publication |
|
Modérateur |
[visibilitymoderator] |
Editeur + modification des droits utilisateurs + assignation de groupes |
|
Associé |
[hidden] |
Editeur Administrateur - Tous les droits |
Un article pourrait ainsi être granulé jusque dans le contenu … 
Fad
Fad on June 6 2007Bonjour à tous,
Concernant la notion de groupe, j'ai eu plusieurs fois la même demande d'utilisateurs d'une version YACS actuellement en test. Ils font partie d'une section restreinte et voudraient pouvoir ecrire un email ou une lettre à tous les utilisateurs de la même section.
Cela se rapprocherait-il du besoin exprimé dans le commentaire précédent au paragraphe "1. Section ou Section-Groupe."
Merci d'avance,
Fad
Bernard on June 6 2007Le commentaire précédent est lumineux, non ? Au-delà des groupes utilisés pour gérer des droits sur des ressources, un autre usage, plus porteur sans doute en environnement web 2.0, est de définir de simples listes d'adresses e-mail.
Dans ce sens, l'idéal serait que chacun puisse préparer ses groupes persos (j'écris à mes potes), sans compter les groupes associées à des listes de diffusion (pour implémenter plusieurs lettres électroniques en //), ou encore à des sections (pour avoir des souscripteurs authentifiés, sans qu'ils aient besoin de s'enregistrer sur le site).
Tof on June 6 2007Euh, tu pourrais développer, Bernard ? je suis tellement d'accord avec ce que tu proposes que je ne vois pas la différence entre un groupe et ta "liste d'adresses mail". Et en quoi cela résoudrait-ce la gestion des droits ?
Fad on June 6 2007" Dans ce sens, l'idéal serait que chacun puisse préparer ses groupes persos ..., sans compter les groupes associées à des listes de diffusion ... , ou encore à des sections .... "
Super ! Ca colle aussi avec un des souhaits des utilisateurs : Pouvoir inscrire quelq'un ou un "groupe" à des lettres ou circulaires à thème.
Y a-t-il une éventualité que ce soit dans les nouvelles fonctions futures ... proches ... euh, j'ose ... très proches ?
Fad
Tof on June 6 2007Fad, vous m'avez éclairé;
Si j'ai compris, au lieu d'autoriser un grope à une entité yacs (section, catégorie, article, etc), on assigne cette entité à un groupe.
C'est intéressant comme approche, ça résoud le problème sans toucher à la gestion de droits existante.
Si c'est bien votre proposition, je vote pour ! sinon ce sera ma proposition, lol.
Bernard on June 6 2007Donc, on est bien d'accord qu'on commence à entrevoir des groupes qui ont leur vie propre. Plutôt que d'y mettre des identifiants ou des surnoms de membres enregistrés, on pourrait aussi avoir de simples adresses e-mail.
En version 7.6 YACS aura un mécanisme d'invitation de personnes par e-mail pour collaborer à une page, et le mail envoyé aura un lien sécurisé pour authentifier le récipiendaire.
Ceci pourrait être élégamment étendu avec les groupes, pour faciliter le marketing viral et la conquête de la planète...
Pour passer des groupes à la gestion de droits, j'ai point d'idées, mais ça va venir...
Tof on June 22 2007Bernard :
Je viens de découvrir l'existence de la classe Anchor définie dans shared/anchor.php
C'est une super-entité dont héritent les classes Section, Catégorie, Article, etc... (au singulier)
Donc, je précise ma requête qui vise à définir une classe Anchors dont hériteraient Sections, Articles, Categories, etc (au pluriel), le but étant de factoriser le code commun ou similaire à ces classes.
Bernard on June 23 2007Tof: Les grands esprits se rencontrent, puisque j'ai introduit en 7.6 (le 15 juin exactement) une nouvelle classe Anchors pour différentes raisons. Pas d'héritage vers Sections, etc. à ce stade, mais ce pourrait être une évolution naturelle comme tu le souhaites.
Tof on June 27 2007oui j'ai été très surpris l'autre jour quand j'ai voulu créer une classe Anchors, rires... Merci !
Olivier on June 28 2007cela commence à être bien complexe tout cela.
j'espère que yacs va rester aussi simple à utiliser et paramétrer pour un utilisateur lambda comme moi !
Chacha on Nov. 27 2007Bonjour,
La gestion des membres a elle evoluée ?
J'ai bien lu pas mal de commentaires sur le site, mais j'avoue que je n'ai point vu ( mal vu)la façon dont je pourrais régler mon cas .
Structure asso , avec plusieurs centaines de membres, qui a un conseil d'administration, un bureau et bien sur un public , le tout géré par un ( plusieurs) "proprietaire".
Si je dois faire une arborescence :
- "Propriétaire" : Statut Associé ( fait tout)
Ce genre de gestion , proposé par GnapZ ( 21 Mai)me conviendrait pas mal ! Ou en sommes nous ?
A+
Agnès on Jan. 28For some help, you can try google translate.
Agnès
Il n'y a pas de problèmes, que des solutions.
Bernard on May 9L'envoi de messages aux éditeurs d'une section, ou aux usagers membres d'une même catégorie, c'est disponible à partir de YACS version 8.4.
Le principe est de favoriser l'interaction de groupes de deux façons différentes.
Au sein d'un groupe de travail, il est important qu'une personne puisse écrire à tout moment à ses collègues, et pour cela il suffira de visiter l'espace web associé au groupe, puis de cliquer sur 'Envoyer un message'.
Les webmestres peuvent aussi avoir à utiliser ce genre de fonction, par exemple pour notifier certains membres d'un événement les intéressant. La fonction est similaire à celle implementée pour les sections, sauf qu'elle est réservée aux seuls associés.
14 rates 
