Actually, the screenshot I sent was from the view of a user who does not own the document, but should not have been able to share it based on configuration, so perhaps the configuration is wrong or there is a bug, because that user can see and use the Download and Share controls.
If a user should not be able to share a document, should they be able to add it to a new world? That seems like another way to share. Perhaps the "Add to" control should also not appear for such a user... = nate On Tue, Jul 24, 2012 at 5:17 PM, Lucy Appert <[email protected]> wrote: > Right -- for those people, the Share and Download buttons on the upper right > of the content profile do not appear. Something similar happens now between > owners and non-owners of content -- only owners can see a gear in the upper > right of the content profile and from it get the menu to upload a new > version and delete it. Maybe the "share" is redundant for content owners and > that's what you're thinking of? They can share with the "share" button and > also share from the menu in the gear? > > Oh wait -- looking at your screenshot, it looks like the gear has > disappeared from 1.2 to 1.3 or do you not own this piece of content? > > Lucy > > > > On Tue, Jul 24, 2012 at 8:11 PM, Nate Angell <[email protected]> wrote: >> >> Thanks Lucy! >> >> So just to confirm, in this case, "sharing" means...? Clicking on the >> "Share" control in the upper left of a content profile and sharing >> that content with another user by typing in their name as in the >> screenshot below? >> >> If so, depending on configuration of roleCanShareContent, a user may >> not even see that Share control? >> >> Sorry to be dense, but there are so many different ways to "share" >> content, I'm trying to make sure I understand this particular case. >> >> = nate >> >> On Tue, Jul 24, 2012 at 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-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
