> - elle demande d'ajouter du code php dans les squelettes,
> alors que c'est justement le système de squelettes en html
> _sans php_ qui fait le spip un système différent des
autres et
> plus accessibles aux non programmeurs,
Oui, mais il suffira, une fois le truc bien rôdé, de le
transformer en un
tag #ACCES_RESTREINT ou un critère de boucle {restreint} ;
or, pour
l'instant, ce qu'on veut est très flou (pour moi) ; donc
expérimentons
largement, sans avoir à coder inc-calcul-squel, qui n'est
pas très souple ni
très accessible à ceux qui ne connaissent pas spip par coeur.
ok, si c'est intégré au boucle par la suite ça peut le faire.
> - on choisit dans le squelette les éléments qui seront
privés,
> ce n'est en fait pas géré par le système, mais par la
couche
> interface (pas beau!).
Pas tout à fait juste : si la règle est que "vieux=>privé",
il faut bien
mettre cette règle quelque part dans l'espace public ?
Comment espères-tu
prévoir tous les cas ? Veux-tu, par exemple, afficher les
titres (mais pas
le contenu) des liens "privés", ou les masquer ? Autant de
questions
auxquelles on ne peut répondre que dans les squelettes.
Vu comme ça, ok. En fait je ne voyais pas les choses comme ça
car pour moi il n'y avait qu'une seule règle permettant de
dire qu'un élément est privé : sa rubrique est privé, et dans
ce cas il est totalement invisible tant qu'on est pas logé (ni
titre, ni contenu, rien.
Ta version est plus générale mais elle ne spécifie bien ce qui
est privé qu'au niveau de l'interface.
J'y vois qd mm un gros avantage, du coup on peut facilement se
baser sur les mots clefs pour fixer si un elt est privé, et
donc ça devient configurable dans la partie admin.
> A priori si tu fait une recherche avec le moteur tu peux
du coup tomber
> sur des articles privés (je suis pas 100% certain mais il
me semble).
Tu tombes sur les titres, oui, sauf si tu ajoutes le critère
de
confidentialité dans la boucle{recherche}. Parfaitement
logique.
idem, critère de visibilité dans interface, au niveaau
architecture j'aime pas vraimment mais je vais peut-être m'y
faire...
Ca me plait pas totalement mais il est vrai que je ne vois pas
d'autre solution aussi souple. J'y réfléchis...
> - elle demande aussi de coder (re-argh pour les non-
codeurs)
> une fonction 'visiteur_accredite'
Au début, oui, ensuite on les fournit en standard. Mais je
répète : quelle
fonction d'accréditation veux-tu ? Je suis sûr qu'on ne veut
pas les
mêmes...
de fait non, on ne veux visiblement pas les mêmes. Je n'en
avais imaginé qu'une seule : utilisateur inscrit (login+pass)=
utilisateur accrédité.
> - elle n'inclut pas de solution d'administration en ligne
(ni
> pour configurer quelles parties sont privées, ni pour gérer
> une liste d'utilisateurs) , ce qui est pourtant une des
> grandes forces de Spip, et encore une fois va éloigner les
non-
> info.
>
> - Si qq1 veux utiliser un système d'inscription en ligne -
ce
> qui est a priori le besoin le plus courant- il lui reste à
le
> coder (cookies/session + table suppl ds la base)
complètement.
Là, effectivement, je n'avais pas tout dit : il faudrait
revoir la liste des
niveaux d'utilisateurs (champ 'spip_auteurs.statut').
Actuellement : 0minirezo -> admin (ou admin restreint,
bizarrement codé)
1comite -> redacteur
Je pense que ça devrait évoluer de manière à avoir
0 admin
1 admin restreint
2 redacteur
3 auteur
4 visiteurséparer admin et restreint serait une mesure de bon sens. Le
code actuel
laisse trop de choses aux admins restreints. Le
statut 'visiteur' serait
utilisé pour les inscriptions aux listes de diff et à la
partie
publique/restreinte du site ; le statut 'auteur'
correspondrait aux actuels
rédacteurs sans login. Ils apparaissent dans la liste des
auteurs, mais
n'ont pas d'accès à ecrire/
Ensuite, dans la partie "options avancées", on aurait, au
lien de
"ouvrir/ou pas/ à l'inscription de rédacteurs", un choix
ternaire :
"inscription [] de rédacteurs [] de visiteurs [] non."
ok pour ça, 100% d'accord. Je ne mettais mes utilisateurs dans
une base à part uniquement pour toucher le moins possible à la
structure de la base de spip, mais ça serait bcp plus propre
comme ça.
La seule question en suspens, c'est celle de
l'identification dans l'espace
public. Pour ceux qui voudraient un système de cookie, en
particulier : en
effet il est hors de question d'avoir une connexion MySQL
obligatoire pour
checker le cookie à chaque page. Il faudrait donc trouver un
système de
"signature cryptée" qu'on installe dans le cookie, et qui
permet de vérifier
par un simple calcul de son côté que le cookie est bon. Pour
un système de
mot de passe, même topo
comment ça pour les mots de pass même topo ?
Quand tu te logues, il y a une requète qui vérif ton
login/pass et si c'est ok, elle te file un cookie. Après en
effet comment vérifier que le cookie est valable sans faire de
requète ? c'est pas évident, je vais voir si je trouve de la
doc la dessus.
Mais l'inscription ne pose pas de problème fondamental
(juste un 'statut'
supplémentaire, et quelques modifs dans l'espace privé et
dans le tag
#FORMULAIRE_INSCRIPTION ).
yep; ok la dessus
on avance 
P.
"Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13 /mn) ; tél : 08 92 68 13 50 (0,34/mn)"