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<[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 > _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
