[Building Sakai] NeoPortal dropdown tools not honoring permissions

JOSE MARIANO LUJáN GONZáLEZ jmariano at um.es
Tue May 21 04:51:00 PDT 2013


Ok Jeremy,
I closed the jira I opened as a duplicated and comented in SAK-23197 
<https://jira.sakaiproject.org/browse/SAK-23197> the other use case. 
Just to make sure that your patch covers both things.

thanks,
mariano


El 21/05/2013 12:59, Kusnetz, Jeremy escribió:
>
> We fixed this on our end and I attached the patch to the following JIRA:
>
> https://jira.sakaiproject.org/browse/SAK-23197
>
> If this JIRA is different than yours then maybe the patch belongs in 
> your JIRA instead.  I don't think the patch has been evaluated yet but 
> it seems to be working well for us.
>
> *From:*JOSE MARIANO LUJáN GONZáLEZ [mailto:jmariano at um.es]
> *Sent:* Tuesday, May 21, 2013 4:26 AM
> *To:* Matthew Jones
> *Cc:* Steve Swinsburg; Kusnetz, Jeremy; sakai-dev
> *Subject:* Re: [Building Sakai] NeoPortal dropdown tools not honoring 
> permissions
>
> Hi everyone,
>
> I was wondering if such jira was created after this discussion?. We 
> just came across this issue during our 2.9 upgrading plans. I couldn't 
> find such jira so I just created a new one to track the issue, please 
> close it if it is duplicated.
>
> https://jira.sakaiproject.org/browse/SAK-23632
>
> At Murcia, we also make extensive use of 'function.requireds' when 
> creating custom tools that will only be used by instructors. We just 
> started the discussion in the jira so feel free to add your views to 
> find the best solution.
> Thanks, mariano.
>
> El 11/05/2013 0:20, Matthew Jones escribió:
>
>     I agree, sounds like a bug with the pages/site entity and probably
>     something being checked in the portal service or tool directly.
>     You'd need to file a jira. I'd agree it shouldn't pass this and
>     decide afterward.
>
>     On Fri, May 10, 2013 at 6:09 PM, Steve Swinsburg
>     <steve.swinsburg at gmail.com <mailto:steve.swinsburg at gmail.com>> wrote:
>
>     IMO what you see should be what you can access. So the data should
>     return the correct list.
>
>     Cheers
>
>     Steve
>
>     Sent from my iPhone
>
>
>     On 10/05/2013, at 23:21, "Kusnetz, Jeremy" <JKusnetz at APUS.EDU
>     <mailto:JKusnetz at APUS.EDU>> wrote:
>
>         We make extensive use of functions.required to give
>         instructors and students a different set of tools in our instance.
>
>         We found that the list of tools in the dropdown are just all
>         the tools in the site, regardless of what the user should be
>         seeing.  I found JIRA SAK-22982 but it doesn't look like any
>         work has started on it yet.  In my opinion this is a pretty
>         major bug.  While clicking on a tool you aren't supposed to
>         have access to doesn't actually go to that tool, it's still a
>         very confusing experience for the user to see tools that they
>         shouldn't.
>
>         Now it looks like the tool dropdown is driven by the site REST
>         service (/direct/site/SITE_ID/pages.json).  It appears that
>         this service isn't honoring user permissions, and instead is
>         just displaying all the pages in the site.
>
>         We are looking to see if we can fix this problem, but my
>         question to the community is, what is the more correct thing
>         to do? Is the more correct thing to not return any pages/tools
>         that the user shouldn't see?  Or should the JSON contain other
>         variables like functions.required that then can be looked up
>         against the /direct/site/SITE_ID/userPerms.json REST service
>         via the neoportal javascript?
>
>         This message is private and confidential. If you have received
>         it in error, please notify the sender and remove it from your
>         system.
>
>         _______________________________________________
>         sakai-dev mailing list
>         sakai-dev at collab.sakaiproject.org
>         <mailto: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
>         <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
>         subject of "unsubscribe"
>
>
>     _______________________________________________
>     sakai-dev mailing list
>     sakai-dev at collab.sakaiproject.org
>     <mailto: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
>     <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
>     subject of "unsubscribe"
>
>
>
>
>     _______________________________________________
>
>     sakai-dev mailing list
>
>     sakai-dev at collab.sakaiproject.org  <mailto:sakai-dev at collab.sakaiproject.org>
>
>     http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
>       
>
>     TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org  <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>  with a subject of "unsubscribe"
>
>
>
> -- 
> ******************************************
> José Mariano Luján González - Aula Virtual
> Area de Tecnologías de la Información
> y las Comunicaciones Aplicadas (ATICA)
> UNIVERSIDAD DE MURCIA -http://www.um.es
>
> This message is private and confidential. If you have received it in 
> error, please notify the sender and remove it from your system.
>

-- 
******************************************
José Mariano Luján González - Aula Virtual
Area de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
UNIVERSIDAD DE MURCIA - http://www.um.es

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130521/a82265d8/attachment.html 


More information about the sakai-dev mailing list