Cela permet de ne pas scroller tout en bas pour trouver le document qu'on vient d'ajouter.
Notes: 
 - J'espère avoir commité aux bon en endroits (entre les branches et le trunk, je suis perdu). En tout cas, je commit pas sur la v3.0 car n'est plus maintenu que pour raison de sécurité.
 - On se base sur l'idée document et pas sur la date associée au document, pour éviter une jointure peut utile dans le cas présent.
fix #4039

Modifications #EVAL{constante} => #CONST{constante} et #EVAL{chr(91)} ou #EVAL{chr(93)} par \[ et \]

Déplacement des scripts de gestion des modes d'affichages et de gestion du tri des documents dans un fichier à part, réutilisable. Ceci permet aux plugins qui utilisent des listes de documents de bénéficier de ces fonctionnalités.

On ne permet d'afficher dans la "colonne documents" (qui s'affiche lorsqu'on édite un article), qu'une seule fois chaque document.
Effectivement si une liaison de document est présente plusieurs fois (notamment avec le plugin roles_documents), le document
était autant de fois listé.

- une action "desordonner_liens_documents" est ajoutée (un peu sur le même fonctionnement que dissocier_document)
- une action "Réinitialiser l’ordre" est ajouté en fin de liste (visible si un rang_lien au moins est défini)
- les actions affectant l'ensemble des documents en fin de liste sont placées dans une div ".actions-liste"
- les documents déplaçables sont encadrés aussi d'une div (.sortable) essentiellement pour éviter de pouvoir les déplacer au dessus ou au dessous de la pagination ou des actions globales.

Cela permet d'ordonner les documents attachés à des objets éditoriaux. L'ordre est stocké dans la colonne "rang_lien" de la table "spip_documents_liens".

Il permet d'avoir plusieurs types d'affichage différents pour les listes de documents attachés à des objets éditoriaux.

Il n'y a pas d'auteurs sur les documents, autant récupérer cette colonne pour lister le nombre d'utilisations dans le site 

Sur une page de visualisation de documents, mettre le nombre d'utilisations dans un bloc

Report de [99143] : Autorisation manquante (le bouton était affiché, mais l'action ne se faisait pas. Testé en intégrant le formulaire côté public avec utilisateur non connecté).

Report de r89155 : Fix https://core.spip.net/issues/3380 : il faut verifier les droits d'associer/dissocier les documents a un objet dans le formulaire editer objet.
Pour cela on cree 2 autorisations associerdocuments et dissocierdocuments qui par defaut reposent sur autoriser(modifier).
+ n'afficher le lien 'modifier' sur un document que si on a bien le droit de le modifier

Fermeture de boucle inutile certainement présente par erreur (pas nécessaire d'incrémenter la version du paquet pour ça)

Afficher aussi les documents en statut prop dans l'onglet "Non publiés" de la médiathèque, ferme http://core.spip.org/issues/3066

medias,portfolio-documents.html : report de [r71704]. cette action (définitive) mérite bien une confirmation !  (http://forum.spip.net/fr_251453.html)

if (!$.isFunction(window.editbox_init)) { ... } ne semble pas passer avec les navigateurs webkit (testé avec chromium et midori), du coup les liens pourvus d'une classe .editbox (bouton modifier du portfolio par ex.) s'ouvrent dans une nouvelle fenêtre au lieu d'une modalbox. Mes plates excuses.

- Ajout de crochets aux balises SPIP dans le code javascript, sans quoi elles ne passaient pas et le rechargement ajaxReload plantait.
- CSS : on change le ciblage des portfolios sur la classe .portfolios au lieu de #portfolios. De cette façon on peut donner un id unique à chaque portfolio sans perdre la mise en forme.

l'unicite des classes css n'a pas d'interet ? ce sont les selecteurs id qui doivent etre unique pour ne pas generer d'erreur en appelant plusieurs fois l'inclure "portfolio-documents" dans une page.
pour eviter de casser l'existant on vide le parametre id_unique dans l'appel de cet inclure dans medias, et on l'ajoute sur les differents selecteur id de cet inclure .
Aux pages et plugins de fournir ce parametre id_unique en cas de multiples appels a cet inclure sur une meme page.

En esperant que ca convienne a tous.

Afin de pouvoir cibler les 3 blocs #illustrations #portfolio et #documents en javascript, on leur rajoute une classe unique au lieu de leur attribuer un nouvel id unique.
Ainsi on s'assure de ne pas bousculer les CSS (merci Cédric Morin).

Petites modifs au squelette des documents joints à un objet, afin de permettre d'afficher plusieurs portfolios sur une même page sans provoquer d'erreur (le cas se présente avec le plugin albums v2).

 - Identifiant unique pour les blocs 'illustrations', 'documents' et 'portfolio'.
- On ne prend pas en compte la fonction editbox_init (contenue dans medias_edit.js) si elle est déjà chargée.

On ajoute credits dans les champs versionnés

Sur la page d'édition d'un document, pouvoir délier/supprimer le document si on en a les droits

L'inclusion pour les listes des documents afin qu'ils apparaissent dans la recherche... c'est un peu chiant de rechercher un document avec la recherche standard du privé et de tomber sur une page vide

Si on a beaucoup de documents, pouvoir augmenter le nombre de documents visibles de la médiathèque par 10 | 50 | 100 | 500 en fonction du nombre de documents dans le site

Nouvelle option de tri dans la médiathèque : filtrer les documents n'ayant pas de vignette personnalisée

Mise a jour des annees pour les Copyrights (je ne connais pas l'utilite de cette info mais autant s'aligner sur les fichiers du core)

Ferme http://core.spip.org/issues/2618 : libele du lien 'ajouter un document' ou 'ajouter une image' en fonction de la configuration

revert car l'ajax sur le modèle  empêche le refresh dans le cas d'un ajout/sortie du portfolio. La suite sur http://core.spip.org/issues/2521

ne rafraichir que le doc modifié (et rester sur la div accessoirement) - réduit la portée de http://core.spip.org/issues/2521
Hum, je commite sur une extension UNIQUEMENT parce qu'Edgard a dit "gogogo" ET que personne ne m'a insulté sur IRC :-p

Le media d'un document (image, video, audio, file) utilise par convenance dans l'interface ne peut dependre en dur de l'extension du fichier :
avec oEmbed, on peut se retrouver a integrer toute sorte de media au format html
Du coup on revoit la structure de la base :
spip_types_documents porte un champ media_defaut (renommage de l'ancien media) utilise comme valeur par defaut du media si non renseigne quand un document est ajoute
spip_documents porte son propre champ media, qui est peuple en fonction de media_defaut, sauf si renseigne lors de l'ajout du document
(ie via fonction de description ou pipeline)
Revision du code partout ou on referencait media, en dispatchant sur l'un ou l'autre selon les cas
upgrade de la base (en deux fois)

Ajout d'un pipeline afficher_metas_document pour permettre l'affichage des infos techniques complementaires sur un document
increment de la version

- Pas de cache sur le modele document_desc
- on ne peut pas ajaxer chaque modele independamment, car certaines operations modifient la liste complète (deposer dans le portfolio, supprimer, ...)
Il faudrait pouvoir cibler le bloc ajax dans le lien.