[Building Sakai] Content "read" permission and Assignment uploads

[Jim Mezzanotte]

>From my testing, the attachment wouldn't upload without "read"
permission--I found no file in the appropriate Admin WS resources
folder. But I did note that a previously uploaded file is not visible
to a user if you then remove the "read" permission.

In https://jira.sakaiproject.org/browse/KNL-465, there's a suggested
change to how attachments are handled (comment on 14-Apr-2010).

Change from current: /access/content/attachment/b155b7

To: /access/calendar/attachment/b155b7

Apologies if I have this wrong, but I think it would mean the security
service checks by tool and then SecurityAdvisor is used to ignore the
"content.read" permission?

Jim Mezzanotte
Asahi Net International

On Mon, Jun 9, 2014 at 4:34 AM, Adam Marshall <adam.marshall at it.ox.ac.uk> wrote:
> Indeed this is most odd although I believe that the assignment is actually uploaded although to the student it looks like it hasn't been.
>
> We have recently taken the step of not allowing site managers to remove content.read - this permission also controls whether Attachments can be read.
>
> adam
>
> --
>
> ** Note change of email address to adam.marshall at it.ox.ac.uk **
>
> Dr A C Marshall, WebLearn Service Manager, University of Oxford.
> IT Services, 13 Banbury Rd, Oxford. OX2 6NN.
>
>
>
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Stephen Marquard
> Sent: 08 June 2014 14:22
> To: Jim Mezzanotte; sakai-dev at collab.sakaiproject.org
> Subject: Re: [Building Sakai] Content "read" permission and Assignment uploads
>
> Mentioned in this JIRA:
>
> https://jira.sakaiproject.org/browse/KNL-465
>
> It is rather unexpected behaviour.
>
> Regards
> Stephen
>
> ________________________________________
> From: sakai-dev-bounces at collab.sakaiproject.org [sakai-dev-bounces at collab.sakaiproject.org] on behalf of Jim Mezzanotte [jmezzanotte at anisakai.com]
> Sent: 06 June 2014 03:56 PM
> To: sakai-dev at collab.sakaiproject.org
> Subject: [Building Sakai] Content "read" permission and Assignment uploads
>
> I'm trying to figure out how content access is handled for student uploads in Assignments.
>
> >From testing (2.9 and Sakai 10), I've confirmed that a student user
> cannot upload a submission attachment in Assignments if the site's resources "content.read" permission is not enabled for that role.
> Instead of uploading, the system displays "operation could not be completed at this time."
>
> Submission attachments are stored in the Admin Workspace resources.
> The "read" permission controls access to a site's Resources--without this permission, users don't see the tool. But I'm assuming the permission is also tied to access for the Admin WS resources, and that the "content.new" (upload) permission is being handled automatically (since each attachment file gets its own folder).
>
> There might be use cases where content "read" access is not required in a site where assignments are being submitted (for example you might use Drop Box instead). So ideally, there should be no dependency between the "read" permission and upload ability in Assignments. But I'm not sure if this dependency is necessary, given the structure for storage of attachment files.
>
> Thanks in advance to whoever can shed some light on this!
>
> Jim Mezzanotte
> Asahi Net International
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
> ________________________________
>  UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"