Besoins fonctionnels

  • Suivi des modifications de chaque item avec mémoire des modifications, surtout si changement d'auteur (différent du versionning car pas de mémoire du réseau).

  • Stratégies de versionning :

    1. Besoin prioritaire : versionner un item avec sa descendance

    2. Dans certains cas : versionner un atelier (le versionning d'espace semble moins pertinent)

  • Modifications concurrentes :

    • Fonctionnement actuel : création d'un item suffixé de ~conflict si une modification est intervenue entre temps (méthode à la Lotus Notes).

    • Lock / unlock manuel des items : peu réaliste/utilisable dû à l'écriture fragmentée multi-items.

    • Fonctionnement envisageable : lock automatique de l'éditeur dès la 1ère modification dans un éditeur jusqu'à l'enregistrement ou la fermeture de l'éditeur (développement ad-hoc dans Sc).

  • Concept de workspace = espace de travail collaboratif instantané / synchrone associé à un modèle documentaire et potentiellement restreint à certains utilisateurs en lecture et/ou écriture.

  • Autorisations d'accès au sein d'un atelier :

    • Restrictions en écriture : principes d'ACL applicables sur les espaces ou les items. Spécifié manuellement et/ou en fonction du modèle grâce à SCbuilder. Mais attention techniquement : la modification d'un item lié peut entrainer un changement de statut et une modification des propriétés des items parents (même si l'auteur de la modif n'a pas les accès en écriture sur les pères).

    • Restrictions en visibilité : non car la contextualisation des propriétés d'item en fonction de l'auteur n'est pas envisagée.

  • Des items versionnés ou live d'un workspace peuvent posséder un statut « public » : ils constituent des « portes d'entrées » donnant un accès en lecture seule à l'item et à ses descendants. Les items publics sont référençables par des items d'autres ateliers.

    Attention :

    • Appliquer les restrictions d'accès en lecture internes au workspace.

    • Niveaux de compatibilité entre modèles documentaires de workspaces => les propriétés de l'item sont recalculées et propres au workspace pointeur.

  • Des versions d'items (et leur descendance) peuvent être publiées dans des sections publiques (au sens NuxeoDM) pour créer un « grain » (un Document-dossier (DD)[1]). Ce grain peut aussi contenir un ou plusieurs documents générés à partir de cet item (un pdf, un site web, un export xml dans un autre schéma, un extrait textuel dédié à l'indexation full-text, forme génératrice[2] mais avec des liens inter-items en relatifs pour être exportés dans un système tiers ou FG', etc.). Le grain est vu lui-même comme un live document, dont toute modification crée systématiquement une version. Cela permet à celui qui pointe un des contenus du grain de spécifier une version précise ou de pointer le live document pour bénéficier automatiquement de la dernière version publiée du grain.

    • Problème du respect des restrictions d'accès en lecture internes au workspace si publié par un auteur autorisé. Faut-il considérer ces 2 fonctionnalités (publication de grains et restrictions en lecture dans un atelier) structurellement incompatibles ?

  • Des items peuvent référencer des items publiés ou des documents générés associés, voire d'autres documents de la base documentaire de Nuxeo (si le modèle documentaire du workspace de l'item source permet d'intégrer le format de ces documents).

  • Recherche d'items :

    • à partir d'un workspace ou d'un espace

    • à partir d'un item et dans toute sa descendance

    • lorsqu'on cherche un item d'un autre workspace pour le référencer, on peut considérer qu'on sait dans quel workspace on recherche l'item, et la recherche full-text pourrait se limiter aux items déclarés publics sans leur descendance.

  • Recherche de grains publiés :

    • à partir d'une section publique dans les grains