July 07
In 2.4, we have two (or three!) different versions of the filepicker in use.
Filepicker 1, used by Announcements, Schedule & Assignments, allows people to upload local files or attach a copy of an existing Sakai resource. If they attach an existing resource, the tool takes a copy of the file as it was at the moment when it was attached, and stores that in a hidden area of the site. Subsequent changes to the resource will not be reflected in the attachment, as it is a copy.
Filepicker 2, used by Wiki, looks just like the Resources tool, and allows people to create folders, upload files, add web links, etc. They can also link to an existing Sakai resource. If they link to an existing resource, the tool does not make a copy of it, and subsequent changes to the resource will be reflected in the attachement.
Note that the Mailtool allows people to upload files from their desktop in-line, as suggested by Michelle (see attachments)
In revising the use of attachment helper in Velocity tools, we need to decide how each tool should manage its attachments. The attachment helper can attach items as links to the original item or it can make a copy and attach to that copy. The tool can use a SecurityAdviser to grant access to an item to users who are not members of the site where the attachment is made. If we do that, users can create an attachment by linking to a resource in any collection and adding a SecurityAdviser that grants access to the item to users who will see the attachment.
The following table attempts to identify entities for which the attachment helper might need to be modified. For each entity types, it lists the user groups who might create, view and modify attachments.
| Tool | Entity type | Who attaches? | Who views? | Who modifies? | Assigned to |
|---|---|---|---|---|---|
| Announcement | Announcement | Instructor | All users | Instructor | |
| Assignment | Creating & viewing assignment / Marking (grading) assignment | Instructor | Instructor, T/A, Student | Instructor | Harriet |
| Assignment - student | Submitting assignment | Student | Student, T/A, Instructor | Student | Harriet |
| Blog | ? | ? | ? | ? | |
| Calendar | Event | Any user | All users | ? | Jim |
| Discussion | Message | Any user | All users | Creator, maintainer | Kathy |
| Forum | Largely as for original Discussion tool above? | ? | ? | ? | Sean |
| Goal Awareness | ? | ? | ? | ? | |
| Gradebook | ? | ? | ? | ? | |
| Mailtool | ? | ? | ? | ? | |
| Melete | ? | ? | ? | ? | |
| OSP | ? | ? | ? | ? | |
| Syllabus | ? | ? | ? | ? | Clay |
| Tests & Quizzes | ? | ? | ? | ? | |
| Wiki | ? | Any user | All users | Any user | Daphne |
| Worksite Info | No longer applicable - now uses WYSIWYG editor rather than needing web link | ? | ? | ? |
The following table attempts to identify where thse entity types might be found when creating attachments and where they might be stored to afford the right set of access restrictions.
| Tool | Entity type | Who attaches? | Collections to choose from | Links/Copy/User Choice | Where to put new items |
|---|---|---|---|---|---|
| Announcement | Announcement | Instructor | MyWorkspace, course site | Links? | Course site? |
| Assignment | Assignment | Instructor | MyWorkspace, course site | Links? | Course site? |
| Assignment | Submission | Student | MyWorkspace | Copy | MyWorkspace? |
| Assignment | Submission | Instructor | MyWorkspace, course site | Link? | MyWorkspace? |
| Calendar | Event | Any user | MyWorkspace, current site | User Choice? | MyWorkspace? |
| Discussion | Message | Any user | MyWorkspace, current site | User Choice? | Current site? MyWorkspace? |
| Melete | ? | ? | ? | ? | ? |
| Syllabus | ? | ? | ? | ? | ? |
| Tests & Quizzes | ? | ? | ? | ? | ? |
| Wiki | ? | ? | ? | ? | ? |
This work will be done under http://bugs.sakaiproject.org/jira/browse/SAK-4224, and more information may be found in the JIRA ticket.
Please add comments including additions and corrections to these table entries.
Comments (12)
Mar 27, 2006
Michelle Bejian Lotia says:
Why have we decided that just doing copies is not acceptable? In trying to under...Why have we decided that just doing copies is not acceptable? In trying to understand the problem, it seems to me the basic use case is:
Attach something I can see, so that users I send it to can also see it.
Doesn't doing copies for all attachments get around the problems we're having with security for links?
Mar 27, 2006
Jim Eng says:
Some tools (like the OSP tools) NEED links rather than copies. In some cases, a ...Some tools (like the OSP tools) NEED links rather than copies. In some cases, a user wants to attach a link so a change in the original is reflected in the attachment as well as in the original. In other cases, the user wants the opposite. Many many sakai admins have complained about the fact that we allow users to make many copies of the same document instead of linking to it. Also, sakai admins want attachments to come out of users' resources quotas, and that doesn't happen for copies put in the attachments area. There may be other reasons.
Mar 27, 2006
Michelle Bejian Lotia says:
Are there other enduser tools than OSP that need links rather than copies?Are there other end-user tools than OSP that need links rather than copies?
Mar 27, 2006
Lance Speelmon says:
IMHO, attachments are the way to go for general purpose use cases until ContentH...IMHO, attachments are the way to go for general purpose use cases until ContentHosting supports versioning. Linking to content has the side effect of the content changing over time and perhaps even being deleted. I think this is undesirable in most common use cases. The way the attachment works now by copying the resource is a very simple way of versioning.
Mar 27, 2006
Michelle Bejian Lotia says:
If we need to support "attachmentsarelinks", could we do this: attachments of l...If we need to support "attachments-are-links", could we do this:
and represent them as such in the UI?
Mar 27, 2006
Jim Eng says:
The refactored design called for fileuploads to go into a resources collection (...The refactored design called for file-uploads to go into a resources collection (rather than the hidden attachments collection) and then we would link to that file. For files that are already in resources, it called for a link to the file that was already in resources. It also allowed the option of creating a copy of the file and linking to the copy. The redesign did not provide a way to cut off the ability of the user making the attachment to modify the file after it was attached. For assignment submissions (and maybe some other attachments), that is needed. In those cases, the old-fashioned way of doing it worked better.
If nobody has a use case that requires links for any of the velocity tools, I would agree with Michelle and Lance that we should continue doing attachments by making copies and linking to the copies. If someone points out a use case where linking to the original file is needed, we could enable that on a case-by-case basis. We still need to go through this exercise of figuring out what's needed for each tool. Some tools are not really showing the right collections now.
Mar 28, 2006
Michelle Bejian Lotia says:
For "Where to Put New Items" for each of the site types listed, does this indica...For "Where to Put New Items" - for each of the site types listed, does this indicate a hidden attachments collection in that site or something else?
Mar 28, 2006
Michelle Bejian Lotia says:
And why would we choose to store attachments in any site other than the one in w...And - why would we choose to store attachments in any site other than the one in which they were attached to something? I wouldn't choose to store anything in My Workspace that wasn't invoked from there originally - most users still have no idea what that site is about.
Mar 28, 2006
Jim Eng says:
As an example, a document a student is attaching to a submission for an assignme...As an example, a document a student is attaching to a submission for an assignment would not be saved in the course site, even though the student accessed the assignments tool in the course site to create the submission. Maybe we will continue to place those attachments in the hidden "attachments" area. We considered putting them in the student's dropbox for the course or in the student's personal workspace resources folder, but that would require a change in permissions for the dropbox/resources folder so the student would not be able to modify the document after submitting it.
Another example is attachments to assignments made by an instructor. Many instructors want such documents hidden until they open the assignment to the students, so the course resources folder wouldn't be a good choice in that case. We now have the ability for the instructor to attach a document that's in their personal workspace and grant student access to it in the context of the assignment. But others might want to put it somewhere else.
If we decide the norm is to create copies for most attachments, most of this is moot, except we still have the issue of where within sakai a user might want to look for things to attach to a particular kind of entity. And we also have to make sure as we do this that we preserve the correct permissions so people who need to view/modify attachments can do so.
Please understand this page as a request for information and not as a proposal for how it should be.
Mar 28, 2006
Michelle Bejian Lotia says:
Jim, do you think the attached design supports this part of the above? "If we d...Jim, do you think the attached design supports this part of the above?
"If we decide the norm is to create copies for most attachments, most of this is moot, except we still have the issue of where within sakai a user might want to look for things to attach to a particular kind of entity. And we also have to make sure as we do this that we preserve the correct permissions so people who need to view/modify attachments can do so."
I designed it such that copies and links were more explicit.
Mar 28, 2006
Jim Eng says:
I like the idea of trying to make the attachment helper act like a modal dialog ...I like the idea of trying to make the attachment helper act like a modal dialog that appears in front of the current page (rather than replacing it) and simplifying the user's choices.
If "the norm is to create copies for most attachments" then the action link in the upper right corner of the dialog on page 4 would probably be "Select a file in Resources", as would the heading on pages 6-8.
On page 8, we might see a button for "Attach a copy" and a button for "Attach a link" once some items are in view with checkboxes checked. Before that, the buttons would be greyed out. If the client tool (assignments, in the example) allows only copies, the "Attach a link" button wouldn't be there. If it allows only links, the "Attach a copy" button would be gone. Only if the tool allows both would both buttons be there. Again, the norm might be to allow only copies, and that would be the default if the tool doesn't specify.
But those labels ("Attach a copy" and "Attach a link") are confusing. We can do better. Or maybe this is an unnecessary complication.
Jul 12, 2007
Beth Kirschner says:
When designing OSP pages (portfolios, forms, etc), I often find myself needing t...When designing OSP pages (portfolios, forms, etc), I often find myself needing to first "remove" a file and then "select" it's replacement. It would be much simpler if user's were offered the option to select-and-replace.