[Using Sakai] Assignment attachments
John Leasia
jleasia at umich.edu
Wed Nov 18 05:06:47 PST 2009
Yes that's mostly it. The first attachment made in a site causes a
folder to be created with the current sites name (so if the site had
been renamed before an attachment was made, the folder would not have
the original site name). But in general, the attachment folder is the
original site name. The attachment folder's URL reflects the site's id,
which doesn't change through any renaming of the site. Attachment urls
reflect the site id. The folder name in Admin's Resources/Attachments
reflects the original site name.
The folder name is buried in a binary entity in the db though, so it
would be hard to find. If you know the site_id, you could try something like
select * from content_collection
where in_collection = '/attachment/'
and collection_id = '/attachment/<insert site id here>/'
and then see if you can discern the displayname value from the binary
entity. I'm not sure how to get that via sql, but I could make it out by
looking through the binary goop that was returned.
John
Jean-Francois Leveque wrote:
>Are old site names kind of aliases in the attachment folder in Resources
>tool for the site_id?
>
>If this relationship is kept somewhere, we might have a way to find the
>old site name from the site_id.
>
>Is it the case? How easy is it to get it?
>
>Cheers,
>
>- J-F
>
>Zhen Qian a écrit :
>
>
>>That is right. The attachment url will always have the site_id inside.
>>
>>However, if you look at the attachment folder in Resources tool, the
>>attachment resources are displayed under site names (site name when the
>>site folder was created). So if the site gets renamed afterwards, and
>>you are looking down the attachment folder for that new site name, you
>>won't be able to find it. All attachments created after site renaming
>>still go into the folder named after the old site name, because the site
>>id is unchanged.
>>
>>Just verified this on nightly. So I guess this might be a problem for
>>attachment look up after site renaming.
>>
>>Thanks,
>>
>>- Zhen
>>
>>
>>
>>On Tue, 20 Oct 2009 07:20:01 -0400, John Leasia <jleasia at umich.edu> wrote:
>>
>> I don't think it is site name in an attachment's URL, I think it is
>> site_id. The site_id doesn't change on a rename of the site. For
>> example,
>>
>> /attachment/SITE_ID/Assignments/ASSIGNMENT_ID/FILE_NAME
>>
>> John
>>
>>
>>
>>
>> Sean Keesler wrote:
>>
>> I don't know if the site has been renamed. I haven't maintained the
>> site and there isn't a history of previous site names for me to look
>> through.
>>
>> It sounds as if you are saying that if the site was created and some
>> assignments turned in and THEN the site was renamed, that the
>> resources attachments folder would have the original site name...and
>> its pretty tough to figure out what that folder name used to be
>> (unless you actually made the change yourself).
>>
>> It seems to me that if the purpose of the naming the resource
>> attachment folder with the name of the site is to make it easy to find
>> files, renaming the site would need to rename the resource attachment
>> folder too...
>>
>>
>> Sean Keesler
>> 130 Academy Street
>> Manlius, New York 13104 USA
>> 315-663-7756
>> sean.keesler at threecanoes.com
>>
>>
>>
>> On Mon, Oct 19, 2009 at 11:39 PM, Zhen Qian wrote:
>>
>>
>> Sean:
>>
>> My comments below:
>>
>> On Mon, 19 Oct 2009 21:21:55 -0400, Sean Keesler
>> wrote:
>>
>>
>> I have a question about the workings of Resources and assignments.
>>
>> I know of an implementation that for some reason seems to have a lot
>> of "lost" assignment submissions. Reportedly, the students are getting
>> their receipts, but faculty are often not able to find the files. The
>> IT group has taken a shine to going into Admin Workspace and using the
>> Resources tool to drill down through the "attachments > {Class Name} >
>> Assignments > {Name of file} > {Name of file}" to seek out these
>> "missing assignments'.
>>
>> Ignoring the fact that this shouldn't be necessary at all....
>>
>>
>> Assignments tool, along with many other tools (e.g. Announcement,
>> Syllabus), uses FilePicker and hence the addAttachmentResource() function
>> of ContentHostingService for uploading attachment resources.
>>
>> You can check BaseContentService for the implementation of the above
>> function. Basically the routine will create the attachment folder and
>> insert attachment at proper place. Every attachment added will get a unique
>> parent folder, with the url structure similar to the following:
>>
>> /attachment/9e8b3ef2-0e5c-4aa0-9289-dd18079b3b56/Syllabus/e94d2485-4089-4eb3-b3a3-71568b0c614c/
>>
>> In order to make attachment file lookup more easier, human-readable folder
>> names have been assigned to the folders, so the above folder path will look
>> like:
>>
>> /attachment/SITE_NAME/Syllabus/ATTACHMENT_FILE_NAME/ATTACHMENT_FILE_NAME
>>
>> This is just an interpretation of the attachment path. However, I don't
>> know why the last containing folder's display name should be as same as the
>> actual file name. Or whether this extra folder is necessary at all as you
>> suggested above.
>>
>>
>>
>> There is one class that doesn't seem to have a folder in the
>> "attachments" section of resources, even though students have turned
>> in assignments in that class with file attachments.
>>
>> Is that pretty normal? How is that supposed to work?
>>
>>
>> Has the site ever been renamed in the past and student submitted assignment
>> attachment when the site was still using the old name? According to the
>> addAttachmentResource, the "site title" section for the attachment url was
>> created with site name at that time, see below:
>>
>> ....
>> String siteCollection = ATTACHMENTS_COLLECTION + siteId +
>> Entity.SEPARATOR;
>> try
>> {
>> checkCollection(siteCollection);
>> }
>> catch (Exception e)
>> {
>> // add this collection
>> ContentCollectionEdit siteEdit = addCollection(siteCollection);
>> try
>> {
>> String siteTitle = m_siteService.getSite(site).getTitle();
>> siteEdit.getPropertiesEdit().addProperty(ResourceProperties.PROP_DISPLAY_NAME,
>> siteTitle);
>> }
>> catch (Exception e1)
>> {
>> siteEdit.getPropertiesEdit().addProperty(ResourceProperties.PROP_DISPLAY_NAME,
>> site);
>> }
>> commitCollection(siteEdit);
>> }
>> ...
>>
>> Thanks,
>>
>> - Zhen
>>
>>
>>
>> _______________________________________________
>> sakai-user mailing list
>> sakai-user at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>>
>> TO UNSUBSCRIBE: send email to sakai-user-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>>
>>
>>--
>>
>>-------------------------------
>>Software Developer
>>University of Michigan
>>734-647-6343
>>-------------------------------
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>sakai-user mailing list
>>sakai-user at collab.sakaiproject.org
>>http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>>
>>TO UNSUBSCRIBE: send email to sakai-user-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20091118/09d91c4d/attachment-0001.html
More information about the sakai-user
mailing list