amelioration de l'API pour editer un article, et des notifications (en effet comme la notification a besoin de calculer l'url et d'avoir le bon contenu texte, on doit la faire APRES sauvegarde des donnees)

petit chambardement d'API pour les rubriques, breves et articles, avec l'idee d'unifier progressivement tout ca

preserve l'environnement (2Ko d'economie sur le source quand meme .. :p )

GROS HACK pour le plugin async_upload, permettant d'avoir un upload de document (ou d'image) sur un article pas encore cree

[7637]: éviter d'oublier le petit dernier et de supprimer les mouchards.

le message 'attention XXX a travaillé sur cet article il y a N minutes' affiche l'IP si l'auteur est anonyme (mode wiki)

Depuis la mise sous forme d'action (tache #605) de la modification d'un article, il était possible à un admin restreint de publier un article dans n'importe quelle rubrique, après l'avoir publié dans une des siennes. A présent cette tentative mettre l'article comme "soumis à publication" dans la rubrique visée.

A noter aussi un petit bug qui empechait un article déplacé d'hériter de langue de sa nouvelle rubrique si celle-ci l'exigeait.

API de editer_article pour permettre de l'editer avec un array() qu'on lui passe directement (ne marche pas avec les champs extra... fatigant ce truc)

Correction #557 au bulldozer: tous les fichiers appelant une fonction _action incluent d'office inc/actions

Auparavant ces scripts concernaient des actions assez marginales de la vie du site. Maintenant qu'ils se démultiplient pour permettre des actions en AJAX et des pages de présentation conformes au modèle REST pour tous les formulaires de l'espace privé, il devient plus important de se protéger contre le tristement célèbre "homme du milieu". En conséquence, le protocole de vérification de la recevabilité de l'action demandée est à présent plus strict.

Normalement cela devrait etre transparent aux utilisateurs honnetes, toutefois il est plus prudent d'essayer cette version localement avant un déploiement sur site.

restauration de la fonctionnalite (longtemps morte) de creation de l'article dans la langue de l'auteur (si le reglage le permet : langue autorisee + menu de trad sur les articles)

API: action/editer_article se satisfait grosso modo de ce qu'on lui envoie : id_article+titre => il ne change que le titre ; id_article+id_rubrique => il ne change que la rubrique, etc. // reste a regler le cas des liens de traduction, qui est plein de code mort

probleme lors de la creation d'article sans preciser id_rubrique : l'insertion du nouvel article se faisait bien dans le premier secteur, mais la suite donnait a l'article une langue vide (Reda)

API: plus besoin de passer les donnees qu'on ne veut pas changer en <input type='hidden'> ; devrait permettre d'utiliser action/editer_article a partir d'un formulaire reduit (qui ne toucherait que le titre et descriptif, par exemple)

les modeles, suite : maintenant ils peuvent avoir connaissance des liens qui les entourent (on sait donc gerer proprement [<doc1>->url]) + divers petits bugs

Gestion en dehors de articles.php des 2 modifs de id_trad. Le test de traduction redondante ne marche pas, mais il semble que cela remonte à loin (la faute de syntaxe dans les attributs en cas de message d'erreur en est un autre indice). A noter aussi que le petit triangle donnant aux formulaires sur les traductions ne tourne pas. Mais on n'est pas loin de la mise en Ajax de tout le bloc sur les traductions.

par exec/articles.php. Toutefois, la gestion de id_trad est encore assurée par celui-ci, le script action/editer_article lui donnant les informations pour ce faire (provisoire en attendant de bien cerner tous les cas d'appels).