Feature Proposal: Implement Collaborative Editing Flow for attachments

Motivation

After three years of using twiki with more than a hundred users, the main feature that we miss daily, and is forcing us to consider switching to MS-sharepoint is the ability to work at several on an excel spreadsheet, or a MS-project, or a word document

Description and Documentation

Change rendering of attachment links to display the file with a little postfixed icon reflecting the locking state: checkedin, checkedout.

When the file is checkedout, the user will be redirected to the attachment manage page where all the versions of that attachment are listed, and a clear message indicating who has the file and since when.

If the file is not checkedout, the link points to the file itself as in twiki 4.1.2.

Examples

Impact and Available Solutions

Implementation

-- Contributors: GillesEricDescamps

Discussion

-- GillesEricDescamps - 01 May 2007

Ok, let's see what this would need....

• If the file is not checked out, we need an extra link to check out, preferably directly in the attachment table. Clicking this link would behave like clicking the "download" link to the file, plus toggling the "checked out" state. Sort of a "save" action (because the state needs to be written to disk) redirecting to the usual viewfile or pub URL of the attachment.
• If the file is checked out, we need at least a possibility to "check in", which would be a combination of another save (flip the status back) and an upload. Only the user who checked out should be allowed to check in. Additionally, all users get (according to your requirement) the "manage" page, plus the information who has checked out. In a collaborative environment neither download nor upload need to be forbidden while the file is checked out.

I am afraid this can not be achieved without Perl programming, but it looks like something which can be done by a plugin using REST actions. Probably the really ugly part is the interaction of the plugin with the TWikiSkins, which are plugins themselves and have their own ideas about how an attachment table should look like (and how to code this in the templates directory).

-- HaraldJoerg - 02 May 2007

Agreed, a plugin is the way to go. There are already handlers in place that should suffice if you can overcome the UI issues. I have some REST handlers for topic and attachment saves (unpublished) that might come in handy.

-- CrawfordCurrie - 02 May 2007

I see this request relatively often in a corporate environment. It would be nice to have an checkin/checkout feature for attachments (optional if enabled), in the core or a plugin. In the WikiWay, it should be possible to break a lock though; the audit trail with SoftSecurity brings accountability.

-- PeterThoeny - 08 May 2007