Généralisation du 8e argument de la fonction spip_connect_db: on accepte maintenant un tableau de longueur 1: 'nom d'authentification' => 'fichier de connexion',
l'ancien format "chaîne de caractères" étant toujours pris en charge avec son a priori que le nom de l'authentification est "ldap".
Ce 8e argument est mémorisé dans l'index "authentification" de la globale "connexion" décrivant l'installation.
Cette mémorisation du 8e argument est effectuée par spip_connect_db qui ne le transmet plus aux fonctions de portage SQL qui n'auraient en fait jamais dû le recevoir.

supprimer le cache du bandeau stocke en meta : ca fait un trop gros volume d'info charge a chaque hit, et en plus il n'etait pas utilise par la faute d'un bug.
On revient a du code simple, et on cachera en fichier dans tmp/ si necessaire

plutot qu'un double redirect, on fait un appel a insert_groupe_mot de action/editer_groupe_mot que l'on implemente pour l'occasion, sur le modele des autres action/editer

Ok ([14605] et [14610]), pour chercher un mot dans plusieurs groupes, mais autant utiliser l'interface SPIP-SQL à fond, du moment qu'on sécurise en amont, sécurisation qui révèle une drôle de chose: si le mot est créé, c'est forcément dans le premier groupe donné. C'est bien l'intention ?

On nettoie pour eviter de garder du code ldap intrique dans le core, mais cela cacherait-il une fonctionnalite qui meriterait de remonter dans l'api auth/ldap ?

ajouter un 3e argument explicite a la fonction auth_ldap_search pour ne pas risquer un trou de secu et accepter une identification avec un pass vide si l'appel ne verifie pas ce point.
factoriser les verifications elementaires sur le login et le pass dans la fonction auth_ldap_search

Plutôt que de dupliquer une fonction ([14601]), généraliser une fonction existante pour éviter que les éventuelles surcharges ne voient plus rien passer. Je profite de cette occasion d'intervention sur l'authentification LDAP pour passer en globale le tableau des noms des attributs potentiellement porteurs du login afin de répondre à [http://comments.gmane.org/gmane.comp.web.spip.user/149473 ce message de la liste spip-user], et reporte en stable pour qu'ils puissent résoudre leur problème. Mais revoir le formulaire de déclaration du LDAP pour y indiquer les correspondances entre champs du LDAP et champs de la table auteurs sera à faire tôt ou tard.

boucle(Toto) est pareil que boucle(TOTO), c'est MySQL qui ne les identifie pas avec sa syntaxe {{{ SHOW TABLES LIKE 'TOTO' }}} ; alors que, bien entendu, il interdit de creer une table TOTO si la table toto existe deja...

Amélioration de la portablité des instructions de date SQL. On introduit la foncton {{{sql_date_proche}}}, qui prend en argument un champ de type date (ou équivalente), un nombre entier et une unité de temps en anglais, et qui construit un test SQL répondant vrai si ce champ est compris entre maintenant et l'intervalle de temps indiqué (dans le passé si négatif, dans le futur sinon). Au passage, il apparaît que le remplacement de NOW() par l'équivalent SQL permettrait de faire plus de choses en PHP. Pour l'instant ça reproduit le code SQL antérieur (mais parfois > a été transformé en {{{NOT <}}} ce qui est inexact mais semble sans conséquence). 

Le porte pour MySQL a été reproduit tel quel en PG (en attendant d'y mettre en l'oeuvre l'améioration produite, pour SQLite, je n'ai pas vu où déclarer la fonction.

complement pour #1758 : informer les logins inexistants avec des infos en base correspondant a un login existant ce qui ne permet plus de discriminer les login exsitants ou non

lors de la verification, on ne verifie plus le login separement du mot de passe car certaines methodes ne peuvent retrouver que les deux ensemble
par ailleurs, cela renforce la securite en n'informant plus sur l'existence ou non d'un login (#1758)
de la meme facon, 
page=informer_auteur&var_login=xx
ne renvoie plus rien si le login n'existe pas (mais il faudrait encore ameliorer en envoyant un faux salt calcule selon le login)

et ne pas echouer a son chargement

La clause GROUP BY pléthorique de cette requête avait été introduite manuellement par [9841] au début du portage PG, alors que depuis c'est fait automatiquement dans le fichier reg/pg.php. Retour au GROUP BY simple, beaucoup plus performant en MYSQL, et qui évite à Oracle de râler car on ne peut y faire de GROUP BY sur un BLOB.

J'en profite pour resyncrhoniser les 2 branches 2.0 et 2.1 sur ce fichier, différenciées superficiellement par [14576].

Oracle accepte finalement que ses mot-clés soient utilisés comme nom de colonne si on les met entre apostrophes (mais celles-ci sont refusées quand elles sont inutiles, fallait le savoir). Ca pose des problèmes pour écrire de Trigger, mais on n'a pas besoin du moins dans l'immédiat (et il semblerait qu'on puisse ruser en passant par une vue si ça devient nécessaire).

En conséquence, retour du champ {((mode}}} en rétablissant les fichiers pre[14588]. La MAJ pour les installations ayant chargé cette version restaurera ce nom de champ, les autres auront une mise à jour qui se réduira à changer le numéro de version installée, pas la peine de faire et défaire.

"apparaitre dans les redacteurs connectes" n'est pas une information sur l'auteur, mais une preference d'utilisation de l'espace prive
utiliser l'api editer_auteur dans la mise a jour des preferences

deleguer a inc/auth le soin de decider si login et pass sont modifiables, sans prejuger de la verification des droits a modifier l'auteur considere

il n'y a plus qu'a supprimer legender_auteur et rediriger vers les bonnes fonctions

clarifier Error 403/Status 503 ; report de http://zone.spip.org/trac/spip-zone/changeset/31174/_core_/securite/ecran_securite.php

Incompatibilé forte: Oracle ayant {{{mode}}} comme mot-clé réservé, il ne peut être utilisé dans un champ de table. En conséquence, renommage sous le nom {{{genre}}} du champ {{{mode}}} de la table {{{spip_documents}}}, avec répercussion sur les squelettes et les scripts utilisant cette table. La globale {{{exceptions_des_tables}}} aurait pu éviter l'incompatibilité pour certains squelettes, mais pas pour ceux ayant {{{mode}}} dans leur critères, ni pour les scrips effectuant des requêtes SQL explicites sur cette table.

A noter que la fonction {{{inc_joindre}}} continue à attendre un tableau dont un des index est {{{mode}}}: c'est sans doute étrange mais ça fait du travail en moins. Si on y tient absolument, on pourra aussi le changer: c'est le ''travailler plus pour nommer plus''.

Hum, [14569] ne contrôlait pas si finement que ça l'installation sans erreurs: les bases nouvellement installées en 2.1 depuis ce dépot n'ont pas de numéro de version.

Suite de la mise au carré des alias de tables pour Oracle ([14576]): la fonction {{{inc_afficher_objets}}} (et {{{afficher_articles}}}). Attention, incompatibilité potentielle ici, les clauses SQL fournit éventuellement à cette fonction ne doivent plus utiliser les mêmes alias de tables.

Erreur SQL, suite de [14529]: laisser optionnelle la mention du serveur, sinon c'est l'erreur dans le traitement d'erreur.

preparation du redecoupage des fonctions dans editer_auteur pour etre conforme aux autres action/editer_xx, et passer par l'api auth

debut d'api auth pour generaliser la possibilite de deleguer l'identification a un annuaire distant,
et son implementation pour la methode 'spip' native

Encore des réécritures pour les alias de tables. Attention, cette version de développement devient très instable, avec bientôt des incompatibilités inévitables pour assurer le portage en Oracle. Sauvegarder vos bases avant toute mise à jour.

Oracle assimile la chaîne vide à l'indéfini; en particulier, comparer une chaine non vide à la chaine vide renvoie l'indéfini et non True en vertu de la règle qu'une opération est indéfinie lorsqu'un de ses opérandes l'est. Réécriture du formulaire de login pour ne pas se faire piéger (avec une écriture compatible MySQL: length) ce qui permet d'exécuter ce formulaire, mais il risque d'y avoir d'autres cas.