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