Feature Proposal: Improve attachment handling
See also:
SharePointVsTWiki. Related: Document Management System, DMS
Foswiki's current attachment display is made for a small number of files. To be able to use Foswiki as document repository we need advanced features.
Ideas
Searching
Tagging
- Instead of searching (and better than to copy the file hierarchy) use filter view options with the attachment table. Show only documents of
type, or uploaded since date.
- Tag documents, or classify them by type; add metadata such as author, document type, document status.
- Tag multiple attachments at the same time.
- Tag image attachments to be used as thumbnail when displaying this topic in search results (e.g. the logo of a company on a company topic) * SolrPlugin currently takes the first image attachment found; the next release will look for an
isthumbnail attribute in the attachment metadata
Viewing
- Show attachments from multiple topics filtered on type, date, author, etc., sorted on date, etc.
- Show thumbnail previews of image attachment
- Show a lightbox preview of all attachments
- Paginate large sets of attachments
- Lazy-load the attachment list using ajax not to slow down viewing a topic
- Integrate attachment search/display with edit mode to facilitate referencing files / including images.
- Available with WYSIWYG, but the interface can be improved.
- There is a disabled attachments dialog in NatEditPlugin which should interact with TopicInteractionPlugin's display and upload mechanisms
File handling
- Move multiple attachments at once to a different topic / to trash.
- Download multiple attachments as a ZIP file
- Update topic references with attachment move
Impact and Available Solutions
--
Contributors: ArthurClemens,
MichaelDaum
Discussion
Exciting prospect!
If it could look and (largely) behave as a Windows-explorer type document repository, than that'll certainly keep training times down. Being able to create a folder hierarchy would be a part of this.
In
MsWordToTWikiMLAddOnDev, i've included a link to a VBA macro available for
MediaWiki. Apart from converting the Word file, they are able to instantly upload all data (including all extracted images) to the correct location on the server, making the transition from Word to
MediaWiki a snap. Having some kind of central document repository in TWiki could perhaps help us achieve the same thing...
--
JosMaccabiani - 17 Dec 2006
A little cleanup of this brainstorming topic.
--
ArthurClemens - 22 Dec 2009
ThumbnailPlugin contains the attachutil utility, which is a command-line script for manipulating attachments.
It's particularly good at managing multiple attachments - it will do wildcard attach, remove, etc.
It could easily be packaged as a separate utility.
--
TimotheLitt - 06 Jan 2010
How about the ideas from
http://twiki.org/cgi-bin/view/Plugins/JavaPasteAddOn ?
- Paste pictures from the clipboard to the browser
- Drop files as attachments onto the page using drag-and-drop.
The beta-quality code has been available for close to a decade.
--
MartinCleaver - 27 Jan 2010
I second the idea for an explorer like interface. My colleagues here still mostly use Frontpage (!) and this is the only feature of Frontpage that distinguishes it from Foswiki. Bulk uploading attachments in Foswiki is too time consuming; it detracts from an otherwise excellent tool.
--
JohnPoplett - 17 Feb 2010
There are a couple of uploaders that I recently evaluated. Most promising is
Plupload. It has got support for uploading attachments using
- Adobe Flash
- Google Gears
- HTML 5
- Microsoft Silverlight
- Yahoo BrowserPlus
It allows to specify a preference list of "runtime engines" using the first one that is supported by the current browser. It supports features like chunking, drag&drop and client-side resizing (not supported by all runtime engines though). This software is still quite young being just released 1.0. Out of the box the queuing widgets do not quite support what we need. However, the lower uploader class, which encapsulates the different runtime engines, offers a way to build a custom widget on top.
Independent from this, the new firefox-3.6 implements the
File API w3c spec. While firefox is the first browser to actually implement including drag&drop, hope is that long term browsers will adopt this API step by step. This will allow to create very nice uploader interfaces as can be seen in
this demo (needs firefox-3.6+).
While Plupload does support html5, it does
not make use of File API to that extend. It does however implement the html5 runtime engine using the means available in older firefox versions, as well as in some other browsers that already implement html5 to that level.
That' said I don't think that using a java applet does age well. For now best to do is to give Plupload yet another release cycle and then build an uploader on top of it that satisfies the needs for Foswiki (base authentication, parallel uploads, reassembling of chunking). Note also, that the transfer encoding of Plupload is
not supported by CGI.pm as the net data is posted as an octet-stream. So this needs a bit of work as well. I am currently exporing this as part of a next
UploadPlugin release which will come with a matching upload rest handler. This will allow us to explore these new techniques before adding it to the core.
--
MichaelDaum - 17 Feb 2010
Ping. Something along this lines sure would help the battle here between sharepoint and Foswiki.
--
CraigBowers - 12 Jul 2011
See Also: at top of topic gives: Access Denied
Attention
Access check on
SharePointVsTWiki failed. Action "VIEW": access not allowed on web.
--
CraigBowers - 12 Jul 2011
Attachment handling has been vastly improved using the
TopicInteractionPlugin which integrates plupload. It is the successor of
UploadPlugin.
Wrt
SharePointVsTWiki, yep, there still might be some useful resources in that content. For now the Legacy web is read/write protected by the
ContentMigrationGroup.
--
MichaelDaum - 13 Jul 2011
I'm a newbie/end user, and I have been using wiki pages with forms to store metadata. That way, each document has structured, predefined metadata. I can't do full text search on stored documents, but this does make it relatively simple to include any type of metadata that FosWiki supports in forms, including an autoincrementing document #. And the metadata is searchable using standard FosWiki search tools. Another FosWiki tool that is useful here is users subscribing to the page for automatic notification of changes.
The other thing that I like about this approach is, I can create a wiki page (with the autoinc generated document #) before I need to save the document. That way, I can include the doc # in the file itself when I save it the first time. I'm using my repository to save technical drawings, and the doc# is part of the notes in the drawing.
The thing I can't do right now is control revisions. I can store revisions as separate attachments, but there is no locking/unlocking of revisions, thus no enforceable workflow.
What I like about using FosWiki as a repository is that it is easy to reference stored documents from within other Wiki pages, since I also use FosWiki as a tool during the design process.
--
PaulHarrison - 01 Aug 2011
FWIW There's a semi-commercial
WebDAVContrib which allows you to mount the wiki as a filesystem; it enforces access controls, checks in new revisions, takes care of locking, etc. There's also the new
SolrPlugin which allows you to search in attachment content.
I have many single-attachment-per-topic type structures, and I wish that we'd just let attachments be first class citizens of topics.
Rather than topic text, we have the attachment binary instead.
That way files can have have their own separate lives, with a
DataForm, topic parent, access controls, everything a normal topic has.
--
PaulHarvey - 08 Aug 2011
I second Paul Harvey: "I wish that we'd just let attachments be first class citizens of topics".
That would solve the Attachment version/Topic version sync problem. That being said, I do see a need to store images that are displayed in topics, as children of the topic. And now we're back to the Attachment version/Topic version sync problem...
I still like the idea of "File" type for topics.
--
PaulHarrison - 26 Apr 2012
Added
TopicInteractionPlugin to be used to implement this proposal. See also
AttachmentStorageInCMS.
--
MichaelDaum - 27 Apr 2012
TopicInteractionPlugin is great, thanks a lot! There is one remaining request which I hear a lot from my colleagues, which is uploading images from the clipboard.
TopicInteractionPlugin already implements the uploading machinery, and it also provides an area in the UI which can be used to drop attachments, which makes me think it could be simple to add "upload from clipboard" functionality. Help offered, of course, but I guess I'd need someone to point me into the right direction first...
--
ClausBrod - 07 Mar 2014
Legal Imprint Privacy Policy