[Building Sakai] Clog, JSON and "clog.modify.permissions" issue

[Steve Swinsburg]

I would switch realm.upd to site.upd, since its pretty universal that site.upd is the maintainer/instructor permission so users with that permission should have the sorts of abilities that the ticket describes. That should fix the problem. 

Cheers,
S

Sent from my iPad

On 19/08/2013, at 19:39, Adrian Fish <adrian.r.fish at gmail.com> wrote:

> Does anybody else on the list have thoughts on this? Steve S raised CLOG-76 and I thought at the time it was a perfectly valid request. This has obviously caused some confusion for Daniel - I myself had completely forgotten about the applied side effect of realm.upd turning on clog.modify.permissions.
> 
> Like Steve says in the ticket, backfilling permissions can be a pain, but, on the other hand, experienced Sakai dev knows that there are plenty of scripts around for accomplishing such a task.
> 
> I'd be happy to revert this ticket in trunk; it has caused problems and wasted time for Navarra university, which I now feel guilty about :(
> 
> Cheers,
> Adrian.
> 
> 
> On 19 August 2013 09:31, Daniel Merino <daniel.merino at unavarra.es> wrote:
>> Hi again.
>> 
>> Answering myself, this is caused by
>> https://jira.sakaiproject.org/browse/CLOG-76 , where modify_permissions
>> permission is bypassed by realm.upd permission in
>> getPermissionsForCurrentUserAndSite() function at SakaiProxyImpl.java.
>> 
>> I think that this is not correct, because realm.upd can have some
>> utility for access role. For example IIRC this permission allows to
>> modify public resources. In fact, we have this permission added to our
>> access/student roles since Sakai 2.5.
>> 
>> Having an existing clog.modify_permissions permission available, IMHO it
>> should not be bypassed. I think that modification of permissions through
>> web services is a common task for every sakai admin.
>> 
>> We are going to revert CLOG-76 in our local instance.
>> 
>> Best regards.
>> 
>> PD: If somebody has reasons to think that realm.upd in access role is a
>> bad idea, I also would be happy to know them.
>> 
>> El 14/08/2013 14:44, Daniel Merino escribió:
>> > Hi everybody.
>> >
>> > This is really weird, but we have the permission
>> > "clog.modify.permissions" totally disabled in our production
>> > environment. We have tested that in SAKAI_REALM_RL_FN there is no row
>> > with this function key.
>> >
>> > However, every user can view the permissions button and change
>> > permissions in Clog tool.
>> >
>> >
>> > Tracking the JSON calls that get permissions for Clog, I can see that
>> > this URL:
>> >
>> > https://miaulario.unavarra.es/portal/tool/f916b597-487c-452a-9f9c-b836951b793a/userPerms.json?_=1376482411717
>> >
>> > get these permissions for a maintain user:
>> >
>> > ["clog.comment.create","clog.comment.delete.own","clog.comment.read.any","clog.comment.update.own","clog.modify.permissions","clog.post.create","clog.post.delete.own","clog.post.read.any","clog.post.update.own"]
>> >
>> > and these other permissions for an access user:
>> >
>> > ["clog.comment.create","clog.comment.delete.own","clog.comment.read.any","clog.comment.update.own","clog.modify.permissions","clog.post.read.any"]
>> >
>> > so it seems that clog.modify.permissions is always true, no matter the
>> > real value it has in database. The other permissions are OK.
>> >
>> >
>> > Is this happening to everyone else? I can create a JIRA if this is not
>> > an issue only for us.
>> >
>> > Any idea will be highly appreciated.
>> >
>> > Thanks in advance.
>> > Best regards.
>> 
>> --
>> Daniel Merino Echeverría
>> daniel.merino at unavarra.es
>> Gestor de teleformación - Centro Superior de Innovación Educativa.
>> Tfno: 948-168489 - Universidad Pública de Navarra.
>> --
>> Ser ateo es jugarsela. Si te equivocas, vas al infierno de cabeza. En
>> cambio, si estás en lo cierto, ni te enteras!!! (Perich)
>> _______________________________________________
>> 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"
> 
> _______________________________________________
> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130819/44335f43/attachment.html