Forum CMS Made Simple FR

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 1.11.4
#~ Url du site : en cours
#~ Hébergeur / Soft : gandi.net
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Bonjour Bess et à tous les autres


Voilà longtemps que je ne suis pas venu ici


Dans le backoffice de CMSMS, les utilisateurs créés avec les groupes et leurs permissions (onglets utilisateurs/groupes >sous-onglets) se trouvent enregistrés dans la table 'cms_users`, les groupes dans la table `cms_user_groups` , avec les permissions dans la table `cms_permissions`;
alors que le module FEU (+customContent) crée les utilisateurs dans la table 'cms_module_feusers_users`, les groupes dans la table `cms_module_feusers_groups`...

Ma question : comment faire pour que certains groupes de `cms_module_feusers_groups` disposent des mêmes `cms_permissions` que les `cms_user_groups` ?

Par exemple : pour qu'un groupe 'éditeur' enregistrés par FEU puisse utiliser TinyMCE en FrontEnd sur les pages privées du sites qui lui sont accessibles (balises {edit}, {cms_init_editor}) et en modifier leur contenu (sans passer par le back-office). En l'état des choses, mon groupe editeur[FEU] ne peut avoir accès aux permissions d'éditions du groupe editor [Backoffice].

Sans doute un paramètre de made simple que je n'ai pas enregistré, malgré mes recherches.

Merci pour votre aide

Ne serais-tu pas en train de mélanger des pommes et des poires ?

Je ne sais pas si c'est possible, mais cela m'étonnerai.

Ce que tu peux faire, c'est faire en sorte -grâce aux évènements- qu'à la création d'un user dans l'admin (évènement AddUserPost), tu crées automatiquement un utilisateur dans FEU en le mettant dans un groupe FEU que tu pourras relier aux droits de la table cms_permissions. Un peu de programmation serait donc nécessaire.

Mais je le répète, par nature, dans CMSMS, les utilisateurs de l'admin et les utilisateurs FEU (qui est un module tier) sont entités différentes avec un usage différent. Je sais que certains CMS comme DotNetNuke mélangent les genres mais ce n'est pas le cas ici.

Bonsoir Heriquet

Tout d'abord merci, pour avoir pris le temps de lire et répondre à ma demande. Et excuse-moi de répondre tardivement : mes activités professionnelles ne me laissent plus de temps pour la programmation (malheureusement, car c'est une activité agréable). La nuit, j'essaie de m'y remettre.

Pour revenir au sujet, il ne s'agit nullement de mélange ni de légumes et fruits, ni de torchons et serviettes. D'ailleurs, j'ai un peu passé l'age d'intervenir futilement et de faire perdre le temps des uns et des autres, ainsi que le mien

A l'inverse, il s'agit d'un problème concret que peuvent rencontrer quelques responsables de projets utilisant CMSMS,
du moins ceux qui peuvent etre confrontés à la 3eme contrainte qui suit :

Dans le cadre d'un futur site d'une association, voici les contraintes :

1 - un ou deux administrateurs (ayant des connaissances en informatique, s'occupent du backoffice, quand ils en ont le temps - le temps! ce qui nous manque le plus ! ) - classique
2 - plusieurs centaines d'utilisateurs, membres de l'association, ont accès au frontoffice - tjs classique
3 - parmi ces derniers une petite centaine s'occupe de remplir, modifier... bref alimenter les pages du site communautaire pour les mois et les années qui suivent...mais cela uniquement par le biais du FrontEnd. On peut les nommer "rédacteurs" (ou autre terme) - contrainte moins classique

Ces rédacteurs n'ont généralement aucune connaissance informatique, même si dans les autres domaines, ce sont des gens cultivés. Comme tous utilisateurs basiques, ils n'ont accès au site que par un seul accès ( enregistré sur leur ordi , selon : en favori, marque page, signet ... ) : le nom de domaine, via sa page d'accueil.

D'où l'utilisation du module FEU, fort utile, qui permet de différencier les groupes d'utilisateurs qui se logent sur la page d'accueil. Les utilisateurs créent leur compte, puis en fonction de leur groupe, ont non seulement accès à divers contenus, mais aussi à diverses permissions.

Cependant le module FEU crée des groupes enregistrés dans des tables `cms_module_feusers_* ' dans la BDD.
Alors que les groupes créés par MS se trouvent dansd'autres tables de la BDD. Et bien entendu, les permissions se trouvent dans les tables MS, et non FEU.

Or dans le cas d'espèce décrit ci-dessus, une fraction de l'entité "utilisateurs" ( les rédacteurs) a un usage pour partie identique (gestion des contenus) à l'entité "adlinistrateurs".

Ma question était de savoir s'il y avait possibilité d'octroyer une partie des permissions des groupes MS aux groupes FEU... voire fusionner les groupes.
Aussi, je pensais tout simplement qu'il y avait un réglage initialement prévu dans MS pour ce faire
Ce qui parraissait même logique, puisque FEU n'aurait pu etre qu'un autre moyen d'accès, plus fin, à la gestion des utilisateurs qui est déjà faite par MS.

Donc, Heriquet, pour résumer à tous ceux qui liront ce post, le but est :

- le nouvel utilisateur/rédacteur crée son compte via FEU sur le site et choisit son groupe,
- selon le groupe choisi, il dispose (ou pas) de permissions,
- ces permissions lui permettent d'avoir accès à des contenus supplémentaires dans les pages du site (Ok, normal). Mais des contenus avec permissions comme TinyMCE pour en modifier le contenu (Tiny qui ne fonctionne qu'avec permission MS, il semblerait)

Si quelqu'un connait un balise, ou autre moyen, je n'en serais pas le seul bénéficiaire; cela servira à d'autres aussi

Merci à tous

Cordialement

Bonjoir,
Cmsms n est pas fait pour faire de l edition de contenu sur le frontend à la base.
D autres cms le font mais cette possibilité n existe pas ici.
Il y avait un module qui le faisiat il y a quelque temps, il faudrait chercher dans la forge et voir s il est toujours suivi.
Feu ne gere en rien les users de l admin, les groupes et les users sont logiquement dans d autres tables que celles .de l admin.
Si tu veux faire saisir des contenus par des adherents, seul la gestion des articles le permet.
Il faudrait faire un petit developpement pour faire ce que tu cherches.
Sinon, il y a beaucoup plus simple: créer des accès admin aux gens autorisés.

D'accord avec Jissey... Il y a un droit "Editeur" dans l'admin, et tu peux également créer des comptes utilisateurs.

Certains modules, comme News ou Questions peuvent être attaqués par FEU mais ce sont des exceptions. Les autres modules sont éditables depuis l'admin uniquement.

Plus concrètement, quels sont les contenus que tes utilisateurs devraient pouvoir modifier ? Uniquement des pages "texte" ? Ou aussi des modules ?

Bonsoir Heriquet et Jissey

Veuillez à nouveau m'excuser pour ces qlq jours de retard dans ma réponse (durant lesquels je n'ai pas eu le temps de m'occuper de cela (: d'autant que vous êtes animés d'une célérité tout à fait remarquable dans l'aide que vous apportez et qu'il faut saluer ici.

J'ai bien fini par comprendre que le FEU ne permettait pas de faire accéder les utilisateurs FrontEnd aux permissions. Comme vous vous en rendez aussi compte, pour les sites confrontés à la problématique que j'avais expliquée plus haut, cela est dommage. Cependant, peut etre, qu'un développement ultérieur de ce module FEU le rendra possible, d'autant que lier les tables de permissions aux tables des groupes d'utilisateurs FEU ne doit pas etre trop complexe. Mais ceci est une autre histoire
Bien sur il y a la gestion des groupes par l'admin, mais qui est une solution lourde, nécessitant un fastidieux travail de gestion de comptes et qui n'est pas vraiment adaptée à un site autogéré par une communauté où plusieurs centaines de personnes peuvent rédiger, publier (un peu comme un forum), d'autant que le backend est usuellement destiné au petit groupe de créateurs/gestionnaires du site et non à la multitude des utilisateurs, comme vous le savez.

En ce qui concerne mon besoin personnel, il s'agit uniquement de permettre la modification des pages "texte" + images via l'éditeur (TinyMCE par ex.) du site, aux utilisateurs qui se sont enregistrés via FEU. Pour d'autres responsables de projets utilisant MS, les besoins peuvent etre plus complexes que la seule modification de pages, c'est vrai.

Pour etre plus précis sur mon cas personnel, il s'agit d'un site des anciens d'un grand collège de l'ouest parisien où des milliers de bambins ont usés leur fond de culotte sur les bancs de cette école durant ces 60 dernières années... ils sont aujourd'hui professeurs, écrivains, ingénieurs, directeurs, même responsables de grands groupes français, musiciens, chomeurs, étudiants pour les plus jeunes, etc... mais tous ont en commun une mine de souvenirs, d'anecdotes, de photos... des moments importants de leur enfance qu'ils ont envie de faire partager.... avec les autres, aussi avec ceux qu'ils ont perdu de vue depuis des dizaines d'années....à travers la France ou l'étranger.


Pour revenir à l'aspect conceptuel du site, comme je l'expliquais plus haut, tous ces utilisateurs n'ont accès au site que par un seul accès : le nom de domaine. Certains aiment rédiger, d'autres préfèrent uniquement lire. Tous se connectent via le FEU pour feuilleter les pages du site (certains en lecteurs, d'autres en rédacteurs). Pour ceux (connectés en rédacteurs) qui veulent rajouter aux pages qu'ils consultent : leurs histoires, souvenirs, leurs montages, photos de classes, y placer des noms des camarades dont ils se souviennent etc... la balise {edit} placée dans un bloc "restricted" dans les pages, leur ouvre l'éditeur Tiny.
Ainsi le site est géré directement par la communauté, sans que 2 ou 3 personnes soient dédiées au back-end.

Si quelqu'un pense à un moyen de le faire, sans passer par le backend, ce serait bien utile

Cordialement

Salut,

Il y a un moyen assez simple qui est de coder tes propres modules qui feront exactement ce que tu souhaites ;-).

A moins qu'il n'y ait une solution toute faite dont j'ignore l'existance, je ne suis pas sur que CMSMS pourra t'aider en ne faisant que de la configuration dans ton cas bien précis.

Je sais que DotNetNuke permettait cela du temps où je l'ai utilisé (jusqu'en 2008) et il n'y a pas de raison que ca ait changé. Un seul compte pour l'admin et le frondend qui sont en fait un tout, avec gestion assez fine des droits d'accès.

Si quelqu'un d'autre à mieux à proposer, qu'il se lance .

A+

Autre solution : utiliser les articles.
il est possible de publier des articles depuis le frontend, et si on couple ça à FEU, tu as ta solution.

Sinon, reste 2 modules plus suivis apparemment:
http://dev.cmsmadesimple.org/project/fil...ackage-911
http://dev.cmsmadesimple.org/projects/touchinlineedit

Ca m'étonnerait qu'ils soient compatibles aujourd'hui, mais ils pourraient être adaptés.

Merci Heriquet et Jissey de vous etre penchés sur cette approche de la gestion des permissions par le FEU.

Il faudra que je prenne un peu de temps pour y réfléchir, aussi regarder ces premières pistes...
Peut-etre d'autres personnes ont-elles résolues une approche similaire des permissions d'un site communautaire.


En tout état de cause, ce peut etre une piste de réflexion à soumettre pour aux développeurs d'une future version de FEU



NB : la présence de membres de CMSMS aux CMS days le 25 juin à Paris sera-t-elle effective, Heriquet ?

Nous n'aurons pas de stand cette année (finances oblige) mais apparemment oui nous serons présent ! (pupitre)

Salut,

FEU et l'admin du site sont et resteront à mon avis 2 choses distinctes et indépendantes.

Tous les sites ne nécessitent pas de pouvoir se logger, loin de là.

Par contre il est possible, via la structure modulaire, de créer soi-même des connecteurs, et même à les partager via la forge. Il est tout aussi possible de créer un module similaire mais qui implémente les fonctionnalités dont tu as besoin.

Pour le CMS Day, à l'heure actuelle, il est toujours prévu que certains s'y rendent, dont moi, mais la forme de notre présence dépendra des dons qui auront été faits pour financer cette présence (bénévole à 100% pour les membres qui seront sur place, c'est le stand qui est payant).

Si je ne suis pas en déplacement, je passerais vous voir aux CMS days (avec une bouteille), pour arroser le pupitre, à défaut du stand

hello,
un petit up en passant, j'ai trouvé ça complètement par hasard (ou presque) :
http://www.i-do-this.com/blog/82/15/Allo...tent-pages

Si ça n'aide pas notre ami dom, ça en aidera peut-être d'autres