Feature Proposal: Ability to store attachments of certain types in external CMS

Motivation

The ability to provide more advanced storage capability.Some examples include:

• Checking out and in of content
• Search on data in the content

Description and Documentation

I would love to be able to have Foswiki automatically store attachments in a content management system such as Sharepoint or Alfresco.Right now, we have set up our internal guidelines for Foswiki to have people store Office documents (e.g. Word, Excel) in Sharepoint and link to them from Foswiki, rather than store them in Foswiki, because of the extra capabilities.I am proposing that Foswiki be extended with a flexible back-end attachment management capability:

• The Foswiki admin can add, through a plug-in, capability for storing in various CMS
• The Foswiki admin can specify the "root" location in the CMS for storage of documents managed as attachments through Foswiki (e.g. a single document library for all attachments, or a document library for each web, named identical to the web)
• The Foswiki admin can determine the file types that get stored in the CMS, versus in the local pub directory system (this allows you to keep attached images, for example, stored locally)
• Foswiki would make available certain additional document management actions for documents stored in the CMS, based upon the capabilities of the CMS

Additional possible functionality could include:

• If the CMS's API gives you the functionality, extend Foswiki's search with the capability to search for attachments which contain the specified text
• Provide the capability to search through the CMS's document library for a particular file that you want to attach to a topic, and attach it easily
• Provide the status of an attachment that could be accessed through a macro (e.g. %<nop>ATTACHSTATUS{"attachmentname"}%)

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: EricLandrieu - 26 Apr 2012

Discussion

I like the idea of enabling some, or even all 'attachments' to be in a different 'store'. Similarly, leveraging external search facilities and then aggregating them into the foswiki SEARCH result.

When I last worked on a SharePoint to Foswiki conversion, I did get to a point where I started to contemplate creating a foswiki layer that ran on top of SharePoint - all the backend requirements (datastore, filestore and indexed search) are in Sharepoint, its just missing a Useable User interface.

however doing full integration is not a small body of work, and requires quite a bit of Microsoft, SharePoint and foswiki knowledge. (if anyone is really strongly interested in such a project / product, please contact me )

conversly, perhaps MichaelDaum's CmisPlugin may make the attachment store linking possible.

-- SvenDowideit - 27 Apr 2012

That's indeed what CmisPlugin is intended for. The current implementation of cmis-perl already allows to navigate and up and download binary files to CMSes supporting CMIS, e.g. Alfresco. In Foswiki, attachments can be visualized using a %CMIS macro. Missing feature is to orchestrate the user's browser to upload an attachment into the "right" place of a CMS, or to mediate in doing so where files are firsts uploaded to Foswiki and then transported further to the CMS using the current cmis-perl bindings.

There are other usability requirements as listed in ImproveAttachmentHandling.

-- MichaelDaum - 27 Apr 2012

Commenting is disabled while not logged in