I agree with Micheal that a general solution with a good UI is important. However I think we are going to end up doing a Pind's Rule of 5 here at Sloan and hack it 5 times till we really understand what we need and how both our users and our lawyers understand the issues.
So we can work together as a community, I'm posting the use case I am programming to today.
Guest/read_private_data use case:
Alumni Notes Community
In general we do not want to give alumni read_private_data privilege.
However in certain communities we (such as the alumni notes community) they need to be able to access forums so they do need read_private_data.
We do want alumni to be able to browse communities and classes so we can not make them Limited Access Users.
Proposed Short Term Solution:
Check read_private_data at the dotLRN level. BUT let communities override it through a link on the control panel and give all members this privilege (probably by not checking it at all).
Do not let classes override. - Classes are covered by the Buckley amendment, Communities are not. By default we give communities and classes the same protection, but we are not obligated to give communities this legal protection.
