Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Allow institutions to remove certain roles, such as guests, from inclusion in the portal chat

Description

Problem: Chat will currently show every user who is logged on to all other members of the site. Sometimes, guests are added to a course site that don't have anything to do with the course itself--they are instructors who want to learn more about the course, or auditors, or if the site is joinable, people who just happened to join it. FERPA laws would probably discourage showing student names to people who are not formally associated with the course.

Solution: allow the superusers of the CLE installation to block specific roles, namely guests, from using Chat across all course sites. (I don't think this option needs to be given to owners of the sites, as it would start to clutter the interface).
There are two possibilities
a) This blocks guests from chatting with other students, but not from other roles, like instructor, TA, or other guest
b) This blocks guest from chatting with anyone in the site. A guest would then see "Chat is disabled" after "In this Site"

I think "b" might be preferable in this case, as I think this should stay simple and picking "a" over "b" supports only hypothetical cases--others might disagree, but I can't think of a real need for this.

Attachments

1
  • 26 Mar 2013, 11:01 AM

Activity

Show:

Hudson CI Server July 15, 2013 at 8:37 AM

Integrated in portal trunk #1573 (See http://builds.sakaiproject.org:8080/job/portal%20trunk/1573/)
https://sakaiproject.atlassian.net/browse/SAK-23259#icft=SAK-23259

Missed adding some files. Doh! (Revision 127022)

Result = SUCCESS

Adrian Fish July 15, 2013 at 7:55 AM
Edited

Fixed in r127018 and r127022

Thanks for the patch. I took out the permission caching code as permissions get cached in the security service and caching them once more will potentially lead to an extended TTL for the permissions.

Adrian Fish July 12, 2013 at 5:15 PM

Tania, what's the purpose of the ChatCacheRefresher? The refresh method does nothing except return null. Can it be removed, or does it need some more work?

Adrian Fish July 12, 2013 at 8:22 AM

Are you ok with the copyright being transferred to the Sakai foundation? Or Apereo? As a rule we transfer all copyright to the foundation.

Tania Tritean March 26, 2013 at 11:01 AM

We did a fix for this.
The fix is attached in the patch.

The solution we build is like this:

All users with a specific permission in their 'My Workspace' site can see the chat (if the chat is enabled on the entire portal).

The users with the chat permission can chat only with other students with same permission(the list of connections and users in site will be filtered based on the permission).

If the user has the permission in 'My Workspace' he will be able to see the chat in the entire portal (not only in his workspace, but in all sites - it is a user type based permission let's say)

Setting the permission in any other sites than MyWorkspace has no value.

In order to avoid performance problem( to avoid too many calls to the security service to find out of the user has or not the permission) we cached the permissions for chat for users. The cache is updated based on realm.upd events.

permission: portal.chat.use
cache name: org.sakaiproject.portal.chat.permissions

Fixed

Details

Priority

Affects versions

Fix versions

Components

Assignee

Reporter

Labels

Property addition/change required

Yes

Created February 20, 2013 at 4:31 PM
Updated July 21, 2016 at 3:40 PM
Resolved July 15, 2013 at 7:55 AM

Flag notifications