Mots-clés : administration, mode collaboratif, nouvelles fonctionnalités, Privé/public
Le fichier de mots de passe pour les sites privés collaboratifs (un mot de passe par utilisateur, en lecture comme en écriture) est maintenant généré automatiquement à chaque changement : nouvel utilisateur, invitation de nombreux utilisateurs, changement de mot de passe d'un utilisateur.
Il semble qu'il y ait une demande pour des sites avec des parties publiques et des parties privés (voir par exemple les commentaires de Fix et Jean-Michel). Il va falloir qu'on trouve une façon intelligente de faire celà. Les idées sont les bienvenues !
D'autres articles sur des thèmes similaires :
- Textes privés et publics - 09/05/05
- Un site privé collaboratif ? - 21/02/05
- Inscription sur les sites collaboratifs, et lien vers le blog des utilisateurs - 15/10/06
- Expéditeur des invitations à participer à un site collaboratif - 28/03/05
- Envoi d'un bulletin d'information aux participants à un weblog - 08/03/05
- Limiter l'accès à un groupe -- FAIT autrement - 18/12/07
- Rendre accessible par mot de passe certaines rubriques - 23/10/07
- Rubrique à accès restreint -- fait - 22/11/06
- Mot de passe sur un blog privé - 27/07/06
- Message vocal - 12/07/05
Oh que oui il y a des besoins !!!
Déjà, pouvoir gérer à partir d'une seule URL principale xxx.yyy.com/ "plusieurs blogs" (... et donc "une" interface admin_top). Je mets cela entre guillemets, mais Typepad par ex. le permet. Cela donnerait par ex. aux associations la possibilité d'avoir des parties visiteurs, membres, conseil d'administration, etc.
Typepad (et d'autres) le font avec des URL distinctes : xxx.yyy.com/a/ xxx.yyy.com/b/ etc.
Il y a d'autres façons de procéder, offrant beaucoup plus de souplesse dans les usages et l'administration du site. L'idée générale est d'associer un utilisateur + des droits d'une part, un document + des droits d'autre part.
Les droits sont classiques : savoir que le doc. existe, lire le doc, modifier le doc, etc.
Le monde wiki (pour ne pas parler des CMS) connaît bien ce genre de problématique. Il y a peut être là une inspiration à trouver. Il serait sans doute préférable de définir d'abord l'enveloppe maximale des besoins / usages. Ceci permettrait que de premières applications simples ne soient pas "incompatibles" avec d'éventuelles réalisations ultérieures.
Cela dit, que penses tu de mes lapins + carottes (usage de mots-clés spéciaux pour aider à administrer groupes d'utilisateurs, de documents) ?