Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Create a directory called C:\temp\myGroups\org.jasig.portal.security.IPerson.
    In this directory, using a text editor like Notepad, create a new file named Special_Developers (not Special_Developers.txt). Add the following 2 lines containing names of portal users:
  • student
  • faculty

Save the file. You have now created a group calledSpecial_Developersthat contains 2 members,studentandfaculty.

...

  1. Log off developer and log on as faculty. You should now be able to subscribe to the new channel. Do so.
  2. Using your text editor, edit Special_Developers and remove faculty from the group by commenting out the faculty line:
  • student
  • #faculty
  1. Still logged on as faculty, refresh your browser. The new channel should still successfully render. Why? Although faculty is no longer a member of Special_Developers,the filesystem group service is externally-managed (you edited it with a text editor). While the filesystem service itself stays up-to-date by checking file timestamps, it has no way of knowing what has changed or that previously-cached membership information for a particular group member is now out of sync.
  2. On the other hand, if you remove Special_Developers from Developers using Groups Manager, this change will be visible in real time because Developers belongs to an internally-managed service. As soon as you refresh faculty's browser, the Channel Admin link will disappear from the header. You'll need 2 different user agents (browser types) on your workstation to try this, one for faculty and one for admin to make the change in Groups Manager.)
  3. Log off and log on once again as faculty. This time, the new channel should fail to render, and the Error Channel should appear in its place with the annoying "You are not authorized to view this channel" message. The Channel Admin link should also be gone from the header. The memberships for faculty are now correctly assessed because membership information for a user is un-cached when the user's session is destroyed.