Uploaded image for project: 'Repository'
  1. Repository
  2. REPO-868

Review requirements for retrieving and managing file/folder symbolic links (aka document links or shortcuts)

    Details

      Description

      The "Nodes" REST API under development enables any type of node to be created. This includes file/folder links that may be thought of as "symbolic" links that point to a target (destination) node. These links may also be known as "Document Links" (although they can also point to a folder, as well as a file).

      File/Folder links are of type "app:filelink" and "app:folderlink" respectively. The target node is specified via the "cm:destination" property.

      We should review the requirement to allow these links to be managed (CRUD) indirectly via the Nodes API. If we do allow these to be created & updated, then we should also review the validation and behaviour.

      Background
      File/folder links used to be supported by Alfresco Explorer (which is no longer part of 5.0+). Share will display these links, if present. Aikau can also use these links, via the v0 REST API (see ACE-3984).

      Open Questions

      • should we allow direct C/U/D of node links via the Nodes API
      • the DocumentLinkService (as implemented for ACE-3984) only allows creation of file or folder links (not arbitrary node links) ... this might be reasonable, eg. in the future arbitrary node links in the repo could (should ?) be implemented via peer associations
      • should we improve validation (eg. via type behaviours) to ensure consistent validation/behaviour - whether via REST API or other (eg. CMIS)
      • possibly issue when trying to filter by link types (see ACE-5115, ACE-5114)
      • should we return isFolder/isContent if we determine a link is app:folderlink/app:filelink (or sub-types) ? If cm:link, should we try to follow the link at least once (similar to current behaviour in Share) ?
      • how should /node/<node id of link>/comments|tags|ratings|children|(etc) work? Should they return collection data of the link object itself (current behaviour or should it follow the link) ?
      • also consider other operations - for example delete, copy, move & rename (any others ?) should probably act on the link object itself ? See also notes below, eg. for rename.

      Notes

      • it should be noted that links can dangle (eg. when destination is deleted)
      • the DocumentLinkService currently forces the link name to be the target name (maybe we should also optionally allow name to be provided)
      • changing the target name does not affect the link name
      • the link name can be updated (does not affect the target)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jvonka Jan Vonka
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: