Projet esup-ecm

Recherche

Sommaire

Pages enfant
  • Cahier des charges

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Ici on tente de regrouper des documents qui décrivent notre besoin, notre ambition dans Esup-ECM.

Objectif d'une première version stable (esup-ecm)

Actuellement et à court terme, 3 2 points sont à réaliser autour d'ESUP-ECM :

  • Balise Wiki
    Pouvoir gérer les versions Nuxeo au mieux (cf page [A résoudre]) : publier directement une version d'un document dans des sections et non pas uniquement la dernière version comme actuellement (partiellement fait dans le trunk - à débuguer, notamment la partie JSF). *\[1.0\]*
  • Balise Wiki
    Avoir un résolveur d'URL qui permette de récupérer une version publiée d'un document (cf page "A résoudre") : cette URL sera propre (comme actuellement) mais basée directement sur le numéro uid de la version publiée du document, et non sur l'uid du proxy de la version [A faire : avec WebEngine ?]. *\[1.0\]*
  • dépôt et publication d'un ensemble de pages type "site web" (ressource complexe)
  • Balise Wiki
    gestion des groupes (uportal ? ldap \[grouper\] ?)
  • authentification shibboleth
  • support des quotas
  • Finaliser le packaging Esup-Ecm pour faciliter l'installation d'un Nuxeo dans les établissements : buid.xml et 1 fichier de propriétés unique (fait), Nuxeo 5.1.6 (fait), LDAP/CAS (fait), nouveau backend SQL MysQL/PostgresSQL (à faire).
  • Pouvoir gérer les versions Nuxeo au mieux (cf page A résoudre) : publier directement une version d'un document dans des sections et non pas uniquement la dernière version comme actuellement (partiellement fait dans le trunk - à débuguer, notamment la partie JSF).
  • Avoir un résolveur d'URL qui permette de récupérer une version publiée d'un document (cf page "A résoudre") : cette URL sera propre (comme actuellement) mais basée directement sur le numéro uid de la version publiée du document, et non sur l'uid du proxy de la version avec WebEngine ?.

L'essentiel de cette partie est résumée ici : http://nuxeo.univ-rennes1.fr/nuxeo/nxfile/default/0b103cbd-7184-4099-be75-f90842c7d149/file:content/presentation_Nuxeo_fonc.pdf
Notez au passage ici que l'uid de ce document que l'on retrouve dans l'url est propre, malheureusement :

  • le numéro est l'uid du proxy,
  • par défaut une mise à jour du document détruit automatiquement ce proxy,
  • l'ancienne url tombe alors en 404
    =>> pas de pérennité ni d'unicité des versions et des urls publiés par défaut dans Nuxeo

Pour les besoins ORI-OAI, suite à cela on souhaite (orioai-nuxeo) :

  • Balise Wiki
    donner la possibilité d'initier une (ou plusieurs) fiche(s) ORI-OAI depuis une version publiée d'un document [partiellement fait dans le
    trunk,
     trunk]\- pouvoir agir sur toutes les actions du workflow *\[1.0\]*
  • Balise Wiki
    donner la possibilité 
    donner la possibilité
    d'afficher le formulaire auteur depuis Nuxeo (A
    Faire)donner la possibilité de demander la publication de la fiche dans ORI-OAI et depuis Nuxeo (A Faire
     compléter) *\[1.0\]*
  • Balise Wiki
    Une branche esup-ecm utilisant Nuxeo 5.2 (voir la compatibilité des plugins utilisés) et une branche du plugin orioai-nuxeo compatible Nuxeo 5.2. *\[1.0\]*
  • Ne pas pouvoir supprimer des versions référencés dans ori-oai (cohérence fonctionnelle).
  • les modérateurs ORI doivent pouvoir lire les ressources dont  ils doivent valider les fiches descriptives.
  • stockage du fichier depuis ori-oai-workflow (vers Nuxeo ... ou en interne pour une version light de ori-oai-workflow ...).
  • Formaliser les droits/permissions d'un Nuxeo File via une fiche de métadonnées XML dans un format adéquat (format englobant).