Site Wide File Upload

Spec for File Management Overhaul on Hub

Michael Steigman (09/25/09) Updated 11/2/2009

User interface mockups

Big Picture

File management in OpenACS is a complicated affair at the moment. There are
several ways to upload and link to files and this has led to duplicate files, broken links
throughout content blocks and “embedded” files in rich text that are difficult to manage
(among many other issues). We are aiming to unify the file upload, linking and
management model and UI across the site, in order to make it simple to upload, update,
share, reference and delete files.

Organization of Files

To help users in a community or on a site collaborate, weʼd like to allow them to
organize and view files in ways that are intuitive. Taking from OS X, Google, Zoho, Windows et.
al., we envision a series of organizational areas in the files UI corresponding to different
filtering criteria.
Places - within a community, default “places” will include all applications and any other
subfolders the admin wishes to include. All users will see these places.
Views - the views area will include some basic views which should cover a lot of
scenarios (search for in OS Xʼs finder) and will expand with custom views created and
saved on the advanced tab.
Favorites (or bookmarks?) - this organizational area will display folders and files in the
personal file area which the user has marked as interesting anywhere on the site.
Shared - implied by the title, this area shows up in the personal file space and shows
files shared by and to you.

Upload and Linking Mechanisms

We want to allow users to link to/attach/upload files to any type of content and present a
consistent UI when doing this. The easiest way to do this would be to provide the same
interface users normally browse by, as OS X does. The WYSIWYG editor will have to
replicate this environment in a plugin setting. Apps that donʼt use the richtext widget
should be able to “include” a version of the browsing interface that allows for single (and
multiple?) file selection.
Much like hard links in Unix, we envision multiple links to each files. The links should be
viewable at the fileʼs canonical location (visible in the mockups). When no more links to
a file exist, the file can be deleted (think callbacks on link removal). Storing a checksum
for the file upon upload so that we can determine if it already exists within the
community would be beneficial.

Metadata Requirements

We need to be able to map from link to destination file. Within this link, we need to
capture some information - the object weʼre linking from being the primary bit of
information. If this link were to be an instance of a dedicated object type, it could also be
permissioned (i.e., a proxy). It could also point to a particular revision, which would
enable a learning module to point at a stable revision and prevent teaching material
from moving beneath a module author. These do not need to be part of the initial
implementation but should be considered.

Navigation and Page Requirements

We should provide an generic overview page (detailed in the mockups) that describes
the files attached to a piece of content. We need to be able to generate navigation for
content such as wiki pages or forum posts that include a link to the overview page if files
are attached. We also need a single, permanent page to display information about a file (File View in the
mockups).

Shared Folders

Referece Google Docs Shared Folders Feature http://docs.google.com/support/bin/answer.py?hl=en&answer=158074
Reference Zoho Document Management http://www.zoho.com/online-document-management/share-documents-collaborate.html

Use Cases

Upload File From Subsite/Group Files tab

User clicks "Add File" link or button from "Subsite->Files" page.
User sees upload dialog and chooses a file from their computer to upload.
File is added to subsite default folder.
Creation_user is the uploading user.
Parent_id is the default folder for the subsite.
Permissions are inherited from context_id,  all members of subsite can view this file.
Context_id is the default folder for the subsite.

Upload file as attachment to Forums Message (or wiki page, etc.)

(note forums post workflow is not addressed)
User chooses to attach a file to a forum message.
User sees upload dialog and chooses a file from their computer to upload.
File is added to subsite default folder.
Creation_user is the uploading user.
Parent_id is the related object, ie: forum_message
Permissions are inherited from context_id, all members who can see the forum post can see the attached file.
Context_id is the parent_id.

Attach existing file from subsite folder as attachment to Forums Message (or wiki page, etc.)

User chooses to attach a file to a forum message.
User sees file chooser dialog (embedded filter view of subsite files).
User chooses existing file.
Acs_data_link created between forums_message and the uploaded file.

Upload file to personal folder

User browsers to their "workspace" (blah) and chooses Files.
This shows the My Files view.
User chooses Add File.
File is added to user default folder (child of user object).
Parent_id is the user default folder.
Context_id is the parent_id.
Permissions are inherited from the context_id.
Noone else can see or manage these files except the user.

Attach Existing file from personal folder to a forums message etc.

User chooses to attach file to a forums message.
User sees file chooser dialog (embedded filter view of subsite files).
Somehow the user chooses to list My Files and sees a list of all files this user has created.
Use chooses file from personal folder.
User sees message that they will share this file with the group/subsite/community with a checkbox to acknowlege.
A cr_symlink is created (this is the manifestation of "share" in this case.) in the subsite default folder.
Acs_data_link created between symlink and the forums message.
Permissions, parent_id, context_id of original file do not change!
Parent_id of symlink is default folder.
Context_id of symlink is parent_id.
Permissions are inherited from context_id, all members of the subsite can view the symlink (which resolves to the file) as long as it is being shared (the symlink exists.)

View subsite files

User sees a list of files in the subsite folder or any subfolders, that they have permission to see (by default all of them.)
Shows filename/title, description, updated date/time, tags, creation user???
User sees list of Places (packages in the subsite.) Each place filters files that have acs_data_link to objects owned by that package.
User can search filenames(titles/descriptions/tags) using the Search Within feature. Just like google docs. Does not search file contents??
Clicking on a file name opens it but there should be an obvious place to view file information (permissions, revisions, links)
Clicking on a folder shows files/folders in that folder.
User can sort by name or date (asc/desc options, perhaps arrow next to name/date sort option?)
What do we do with pagination? How does search/sort affect pagination?

Experimental!! Sharing a Folder

User creates a folder or chooses an existing folder to share.
Symlink is created in group or target users folders to the shared folder depending on sharing level.
Permissions are granted on the ORIGINAL folder based on the sharing settings. NOTE: how do we do this without screwing something up? That is the sharers are not allowed to DELETE or ADMIN the original folder. But we want to simplify dealing with the items IN that folder.