An additional difficulty in this is that "View" sometimes requires Download. We cannot display previews for all file types, and thus Download is sometimes required for someone to be able to View it. Not allowing Download for certain types and allowing it for others could be quite confusing. On top of that, as pointed out by Nate and Lucy, there are many ways in which the content can be "obtained" anyway.
Kind regards, Nicolaas On 25 Jul 2012, at 20:53, Nate Angell wrote: > We should give an award every year for the longest thread ;) > > Yes, LMSs and Google Docs allow download for documents one can only > view, and anyone can use their mobile phone to grab a pic of what's on > a screen. > > Meanwhile, I field questions from medical education institutions in > particular that don't want anyone to share anything with anyone ever. > They will probably not understand why "view" would also allow > "download", but then again, there's a lot about OAE that doesn't fit > that perspective well ;) > > = nate > > On Wed, Jul 25, 2012 at 12:38 PM, Lucy Appert <[email protected]> wrote: >> One last comment before we put a stake in the heart of this thread >> -- the >> fact you can download something you can't share is exactly the same >> functionality of any LMS. Documents that are posted for students in >> Blackboard and Sakai CLE can be downloaded by those students and >> redistributed. Also, anything that is visible to someone on a >> screen can be >> copied through a screenshot and re-distributed. >> >> Lucy >> >> >> On Wed, Jul 25, 2012 at 11:26 AM, Nate Angell <[email protected]> >> wrote: >>> >>> OK, I think I understand the expected behavior now and see it >>> working >>> as I would expect in the example doc Kent shared on the QA server. >>> >>> It does seem a bit odd that the Add to control would still be >>> visible >>> on the content profile of a document that I can not share, as that >>> document appears to already be a part of my library and there are no >>> other options to Add to—it seems like the Add to control does >>> nothing >>> under these circumstances and would be better off removed like the >>> Share control. I can enter that as an enhancement request if others >>> agree. >>> >>> I note that we are matching Google docs behavior in that I can still >>> download a document that I can not share, which of course means it >>> would be easy for me to share it via email, etc. There are some EDU >>> institutions that would probably prefer to have download disabled >>> also, even tho a clever user could still find ways to share any >>> document they could actually view. >>> >>> I'm still unable to configure the behavior to work correctly on a >>> local build of rSmart's merge of OAE 1.3, but I'll probably have to >>> chalk that up to something about the build or merge and investigate >>> locally. >>> >>> Thanks everyone for helping bring clarity! >>> >>> = nate >>> >>> On Wed, Jul 25, 2012 at 4:16 AM, Lucile G Appert <[email protected]> >>> wrote: >>>> Yep. This is exactly what I was trying to say last night. The >>>> button is >>>> there but it essentially doesn't work for sharing beyond yourself. >>>> >>>> Thanks, Kent. >>>> >>>> Lucy >>>> ________________________________ >>>> From: Kent Fitzgerald <[email protected]> >>>> Date: Wed, 25 Jul 2012 06:39:31 -0400 >>>> To: Sakai OAE User Reference Group<[email protected]> >>>> Cc: [email protected]<[email protected]>; Nicolaas >>>> Matthijs<[email protected]>; Nicolaas >>>> Matthijs<[email protected]>; OAE-Dev >>>> List<[email protected]> >>>> Subject: Re: [oae-urg] what is roleCanShareContent supposed to do? >>>> >>>> For some additional clarity to what was being discussed, the Add To >>>> button >>>> is present on content that you do not have permissions to share, >>>> but it >>>> doesn't allow you to add it to more than My Library, as Nico >>>> indicated. >>>> >>>> If you try to use Add To with that restricted content as part of a >>>> group, >>>> you will not be able to unless you remove that content from your >>>> selection. >>>> >>>> See attached screenshot. >>>> >>>> -- >>>> Kent Fitzgerald >>>> >>>> On Wednesday, July 25, 2012 at 6:26 AM, Ward, Lynn E. wrote: >>>> >>>> Google also allows document owners to prevent editors from sharing >>>> further. >>>> I think this feature would be very useful, but it's definitely >>>> something >>>> that should be controlled at the document level, by the manager. >>>> >>>> Lynn >>>> ========================== >>>> >>>> Lynn Ward, Principal Systems Analyst >>>> >>>> Instructional Technology Systems and Services >>>> >>>> University Information Technology Services >>>> Indiana University >>>> Information Technology and Communications Complex (IT 342K) >>>> 535 West Michigan Street, Indianapolis, IN 46202 >>>> Phone: 317-278-5713 E-mail: [email protected] >>>> >>>> >>>> From: Lucile G Appert <[email protected]> >>>> Reply-To: "[email protected]" <[email protected]>, Sakai OAE User Reference >>>> Group >>>> <[email protected]> >>>> Date: Wednesday, July 25, 2012 6:06 AM >>>> To: Nico <[email protected]>, Nicolaas Matthijs >>>> <[email protected]>, Sakai OAE User Reference Group >>>> <[email protected]>, OAE-Dev List >>>> <[email protected]> >>>> Subject: Re: [oae-urg] what is roleCanShareContent supposed to do? >>>> >>>> The standard setting for most instances would be only Viewers >>>> cannot >>>> share, >>>> right? Institutions could be more draconian and make it so no >>>> role but >>>> owner >>>> could share, or not restrict sharing at all, but generally a >>>> setting of >>>> "Viewer can't share" would be in line with the google role of the >>>> same >>>> name. >>>> If this is the case, this is how I had imagined it would work. The >>>> ability >>>> to allow no roles but owner to share is fine as long as you can >>>> decide >>>> select each of the three individually for no sharing. By the end >>>> of this >>>> exchange, I was getting panicky that sharing had to be turned off >>>> or on >>>> implementation-wide for all roles except owner, rather than on a >>>> role by >>>> role basis. Thanks for explaining -- this is how I had assumed it >>>> would >>>> work >>>> (for Viewer, anyway -- there are actually more choices than I >>>> expected, >>>> which is nice). >>>> >>>> Lucy >>>> ________________________________ >>>> From: Nicolaas Matthijs <[email protected]> >>>> Sender: Nicolaas Matthijs <[email protected]> >>>> Date: Wed, 25 Jul 2012 10:18:14 +0100 >>>> To: Sakai OAE User Reference Group<oae- >>>> [email protected]>; >>>> OAE-Dev >>>> List<[email protected]> >>>> Cc: Lucy Appert<[email protected]> >>>> Subject: Re: [oae-urg] what is roleCanShareContent supposed to do? >>>> >>>> Looks like the oae-dev list got dropped from this. >>>> >>>> Nicolaas >>>> >>>> >>>> On 25 Jul 2012, at 10:15, Nicolaas Matthijs wrote: >>>> >>>> Hi everyone, >>>> >>>> For the 1.3.0 (and the 1.4.0) release, the implementation is >>>> indeed very >>>> close to what Nate has described. There are 3 institution-wide >>>> settings >>>> that >>>> determines which content roles (editors, viewers, everyone logged >>>> in or >>>> anonymous users) can share a piece of content. One of those >>>> settings is >>>> for >>>> public content, another one is for content that's visible to all >>>> logged >>>> in >>>> users and the last on is for private content (content only >>>> visible to >>>> the >>>> people it's been shared with). >>>> >>>> If because of one of those settings, a user is not able to share >>>> a piece >>>> of >>>> content, the Share button will disappear and the Add To button >>>> will have >>>> My >>>> Library (bookmarking purposes) as the only option. >>>> >>>> In this case, sharing actually means all of the following: >>>> >>>> - give another OAE user viewer rights >>>> - add to a library, world, or collection >>>> - share with an external web service via addthis >>>> >>>> If this is no longer working correctly or a certain configuration >>>> is >>>> broken, >>>> it should definitely be reported as a bug and should probably >>>> hold up >>>> the >>>> 1.4.0 release until it's fixed. A quick local test on the 1.4.0 >>>> Release >>>> Candidate does show that it still seems to be working correctly. >>>> >>>> If desired, per-content item control of who can share makes sense >>>> to me >>>> and >>>> can probably be worked into some of the ongoing design work. We >>>> just >>>> have to >>>> make sure that the fine-grainedness of the permissions is >>>> appropriately >>>> layered away in the UI as to not confuse the basic use cases. >>>> >>>> Hope that helps, >>>> Nicolaas >>>> >>>> >>>> >>>> On 25 Jul 2012, at 03:33, Lucy Appert wrote: >>>> >>>> Yes, those buttons should definitely be suppressed (unless they >>>> lead to >>>> nowhere, as is the case in Google). I guess we need to report >>>> this as a >>>> bug? >>>> Nico, are you out there? What do you think? >>>> >>>> On Tue, Jul 24, 2012 at 10:09 PM, Nate Angell <[email protected]> >>>> wrote: >>>> >>>> Also, I notice in the settings Kent provided, private is empty, so >>>> presumably a private doc could not be shared by anyone but a >>>> manager. >>>> >>>> That jives with what I experienced as a user, except that I did >>>> have >>>> download and add to controls, which may give me other ways to >>>> share. >>>> >>>> = nate >>>> >>>> On Jul 24, 2012, at 6:07 PM, Kent Fitzgerald <[email protected]> >>>> wrote: >>>> >>>> I believe oae-demo does not have any modified settings. >>>> >>>> https://qa20-us.sakaiproject.org:8088 is built with the following >>>> settings: >>>> roleCanShareContent: { >>>> 'public': ['editor', 'viewer', 'everyone', 'anon'], >>>> 'everyone': ['editor', 'viewer', 'everyone'], >>>> 'private': [] >>>> >>>> I've shared a private document with Nate (both your users) and >>>> Lucy's >>>> users >>>> on that instance. >>>> >>>> Hope that helps >>>> >>>> -- >>>> Kent Fitzgerald >>>> >>>> On Tuesday, July 24, 2012 at 9:04 PM, Nate Angell wrote: >>>> >>>> hm, my reading of what Lucy describes doesn't exactly match my >>>> reading >>>> of the configuration settings. >>>> >>>> In the configuration settings, global relationships between >>>> document >>>> visibility states (eg, private, everyone, public) and document >>>> roles >>>> (eg, viewer, editor, etc) are established for an entire >>>> implementation. Then a document owner can adjust a document's >>>> visibility and the roles of other users/groups it is explicitly >>>> shared >>>> with to change that document's "sharability", but only among the >>>> global definitions (which will be dang hard to describe methinks). >>>> >>>> Except as I have it configured, I'm not seeing any effects of this >>>> configuration. I have configured an implementation (as below) so >>>> that >>>> I'm expecting no user should be able to share any document, unless >>>> they are a manager of that document. >>>> >>>> Then I created a document, made it private, and shared it with one >>>> other user, giving them a "viewer" role. And that user can still >>>> share >>>> the document. >>>> >>>> roleCanShareContent = { >>>> 'public': [], >>>> 'everyone': [], >>>> 'private': [] >>>> }; >>>> >>>> I have also tried other combinations of configuration and >>>> sharing, but >>>> without any noticeable effects. >>>> >>>> = nate >>>> >>>> On Tue, Jul 24, 2012 at 5:49 PM, Lucy Appert <[email protected]> wrote: >>>> >>>> Right. The ability to restrict sharing must be turned on across an >>>> implementation. Then individual users can choose that setting for >>>> some >>>> content -- it's just one option and users can also continue to >>>> choose to >>>> let >>>> people reshare what they are sharing. Can you tell me what the >>>> setting >>>> for >>>> this user on this piece of content was? Was it something like "View >>>> Only" or >>>> was it shared without restriction? >>>> >>>> >>>> On Tue, Jul 24, 2012 at 8:40 PM, Nate Angell <[email protected]> >>>> wrote: >>>> >>>> >>>> hmmm >>>> >>>> Based on my reading of the roleCanShareContent configuration, it >>>> is a >>>> global setting for an entire implementation that controls what >>>> users >>>> can do with documents, depending on a document's visibility >>>> (private, >>>> everyone, public) and a user's role for that document (eg, viewer, >>>> editor, etc). >>>> >>>> I just am not able to tell what the effects of changing the >>>> configuration should be ;) >>>> >>>> = nate >>>> >>>> On Tue, Jul 24, 2012 at 5:31 PM, Lucy Appert <[email protected]> wrote: >>>> >>>> Oh, this is an item-by-item basis that users activate themselves, >>>> just >>>> like >>>> in Google docs. The equivalent would be "View Only" in google >>>> docs. I'm >>>> not >>>> sure if the notes are saying that institutions could choose not >>>> to turn >>>> that >>>> restricted sharing role on -- in other words, they could keep the >>>> environment like it is now, where anyone who can see something >>>> can share >>>> it. >>>> I don't think there would be many takers for that option, but I >>>> could be >>>> wrong. >>>> >>>> Lucy >>>> >>>> >>>> On Tue, Jul 24, 2012 at 8:25 PM, Bruce D'Arcus <[email protected]> >>>> wrote: >>>> >>>> >>>> Ideally, at some point, resharing in OAE can be controlled on an >>>> item-by-item basis, as with Google+ content? Shouldn't be up to >>>> institutions >>>> to set globally. >>>> >>>> On Jul 24, 2012 5:06 PM, "Lucy Appert" <[email protected]> wrote: >>>> >>>> >>>> Hi Nate, >>>> >>>> In all previous releases, if someone could see a piece of >>>> content, he >>>> or >>>> she could share it. But that's not optimal for some situations, >>>> such >>>> as peer >>>> editing. Student A needs to be able to see Student B's work to >>>> comment >>>> on >>>> it, but Student A should not be able to keep that work and re- >>>> share it >>>> with >>>> other students. Another use case is restricting the sharing of >>>> copyrighted >>>> materials being used in a class. The ability to restricting sharing >>>> was >>>> something requested by most piloting institutions for privacy and >>>> other >>>> reasons. >>>> >>>> Hope this helps. >>>> >>>> Lucy >>>> >>>> On Tue, Jul 24, 2012 at 7:50 PM, Nate Angell <[email protected]> >>>> wrote: >>>> >>>> >>>> in 1.3, I'm a little confused about the expected behavior of the >>>> capability described in the release notes as: >>>> >>>> A new configuration setting is now available that allows >>>> institutions >>>> to configure who is allowed to share content in the system, based >>>> on >>>> the visibility setting of the content >>>> >>>> https://confluence.sakaiproject.org/display/OAEREL/ >>>> oae-1.3.0+release >>>> >>>> I see the notes in config.js (below), but don't really understand >>>> what >>>> privilege is controlled by this configuration setting. Does "share" >>>> here mean: >>>> >>>> give another OAE user viewer rights? >>>> >>>> add to a library, world, or collection? >>>> >>>> share with an external web service via addthis? >>>> >>>> Can someone help me understand by showing me how this configuration >>>> setting would be adjusted to meet a use case? >>>> >>>> /* >>>> * Restrict the ability for a non manager user to share a >>>> content item, depending on their role specified, and the content >>>> permission. >>>> * public - content available to anyone >>>> * everyone - content available to logged in users >>>> * private - content available to private users >>>> */ >>>> roleCanShareContent: { >>>> 'public': ['editor', 'viewer', 'everyone', 'anon'], >>>> 'everyone': ['editor', 'viewer', 'everyone'], >>>> 'private': ['editor', 'viewer'] >>>> }, >>>> >>>> = nate >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> ____________________ >>>> Lucy Appert, PhD >>>> Director of Educational Technology >>>> Liberal Studies Program >>>> New York University >>>> 726 Broadway, Rm. 677 >>>> New York, NY 10003 >>>> (212) 998-7168 >>>> [email protected] >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> >>>> >>>> -- >>>> ____________________ >>>> Lucy Appert, PhD >>>> Director of Educational Technology >>>> Liberal Studies Program >>>> New York University >>>> 726 Broadway, Rm. 677 >>>> New York, NY 10003 >>>> (212) 998-7168 >>>> [email protected] >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> ____________________ >>>> Lucy Appert, PhD >>>> Director of Educational Technology >>>> Liberal Studies Program >>>> New York University >>>> 726 Broadway, Rm. 677 >>>> New York, NY 10003 >>>> (212) 998-7168 >>>> [email protected] >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> >>>> >>>> -- >>>> ____________________ >>>> Lucy Appert, PhD >>>> Director of Educational Technology >>>> Liberal Studies Program >>>> New York University >>>> 726 Broadway, Rm. 677 >>>> New York, NY 10003 >>>> (212) 998-7168 >>>> [email protected] >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >>>> >>>> >>>> _______________________________________________ >>>> oae-urg mailing list >>>> [email protected] >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-urg >>>> >> >> >> >> >> -- >> ____________________ >> Lucy Appert, PhD >> Director of Educational Technology >> Liberal Studies Program >> New York University >> 726 Broadway, Rm. 677 >> New York, NY 10003 >> (212) 998-7168 >> [email protected] _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
