From: Jon M. <jo...@te...> - 2006-04-06 16:19:04
|
I think there are two issues that a user might be concerned about with respect to new messaging functionality 1) the release of their email address to another person and 2) the reception of bulk email on that email address. 1) is a non-issue since the Email address is not revealed to anyone. The 'virtual' process is that the message goes from person A's Bodington account to person B's Bodington account and then from person B's account to person B's email inbox. The 'from' field of the Email will always be the same - a help desk address. (I'm using a single SMTP transaction per recipient so the other recipient's addresses don't appear in the message headers.) 2) could be addressed by a local policy and suitable functionality to implement the policy. You could have global opt-in and opt-out of bulk Email functionality, individual opt-in and opt-out, varying policies of which kind of person can opt in or opt etc. All of the logic can be handled based on group memberships and the system-wide policy can be configured by selecting different combinations of group name. The opt-in and opt-out functionality would require a development of the group membership editor tool and a new permission which I would call 'join'. A user with see, view and join access to a group would be allowed to add themselves or remove themselves from the group but not add and remove other people unless they also have edit access. The user interface would provide them with a simple join/leave button. The user preferences pages could make the join/leave bulk email. Paul Davis wrote: >We have a system whereby people can opt out of disclosing their emails. You >won't find any animal researchers for instance. Email search results are >different inside and outside the university - we have considerable external >presence in the VLE. Any system like this would need to take account of >these preferences, and update in real time > >Maybe we're peculiar, but all these items would need to be taken into >account before we could launch something like this here >Paul >------------------------------------------------------------------------- >Dr Paul V Davis >Acting Head, Learning Technologies Group >Project Manager, WebLearn ( Oxford's version of Bodington.org) >Oxford University Computing Services >13 Banbury Road, Oxford, OX2 6NN >Tel: 01865 283414 > > > > > >-----Original Message----- >From: bod...@li... >[mailto:bod...@li...] On Behalf Of Sean >Mehan >Sent: 06 April 2006 15:42 >To: bod...@li... >Subject: Re: [Bodington-developers] Group email > >This is similar to sending an email to a JISC mailing list, where all >of the members have opted in. This tool gets its data from the bod >db, which might have taken that from >the your SIS. Still, all of these have been opted in. > >This is all about business for teaching and learning, and somewhere >you have been tied into a group because you are associated with it by >some admin's point of view. > >As long as it sits within the org, this should be fine. The real >problem would be if I forwarded yours to my cousin Jimmy. But I could >do that anyway, and is not the fault of this tool. > >Is there not a way at (Your Org Here) to search emails, address book, >or some such. If so, you have already made it a requirement within >(Your Org Here) to release emails for business with informed consent, >because it is in Your Org Here. > >If someone outside Your Org Here can get at these emails, then there >would be a DPA issue. But again, you should only have access to those >emails that sit in your group. Which is a reason for filtering out >all_users. > >s > > >On 6 Apr 2006, at 15:05, Paul Davis wrote: > > > >>Have you looked at the DPA implications of this? You are effectively >>releasing email addresses without asking user permissions. Some of >>our >>groups could run to a couple of hundred people or more >> >>Paul >> >>---------------------------------------------------------------------- >>--- >>Dr Paul V Davis >>Acting Head, Learning Technologies Group >>Project Manager, WebLearn ( Oxford's version of Bodington.org) >>Oxford University Computing Services >>13 Banbury Road, Oxford, OX2 6NN >>Tel: 01865 283414 >> >> >> >> >> >>-----Original Message----- >>From: bod...@li... >>[mailto:bod...@li...] On Behalf Of >>Antony Corfield >>Sent: 06 April 2006 14:50 >>To: bod...@li... >>Subject: [Bodington-developers] Group email >> >>Naomi has been working on functionality to allow users to email all >>(and individual) members of groups that they belong to. The list of >>groups is found by the following select statement: >> >>Group.findGroups("name like '" + zonePrefix + ".%' and group_id in >>(select group_id from members where user_id=" + >>user.getUserId().intValue() + ")"); >> >>at uhi e.g. students and staff are in the 'uhi' zone so this will >>ignore bodington default groups (allusers, allstaff... etc.) and >>localgroup.owners/adhoc. This is pretty general so could I guess go >>into head. Have a look at http://www.dev.clan.uhi.ac.uk/site/ - login >>uhistdnt3/uhistdnt3. >> >>The tricky bit is presenting groups in a logical way. E.g. we have >>uhi.uh.upel70309.staff and uhi.uh.upel70309.students >>(zone.faculty.module.*) so we have some String searching to find the >>corresponding group name depending whether the user is staff or >>student >>and presenting the user with the option of selecting staff or student >>for a given group. This wouldn't be so easy to generalise but could >>possibly be done with a regx set in template or bodington.properties - >>depends of course on how an institution names groups and if this is >>consistent. However, it's not essential and all groups could just be >>presented with full description. >> >>Any interest in this functionality out there? Any suggestions? >> >>Cheers, >>Antony >> >>-- >>Antony Corfield, UHI >>e-Frameworks developer >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking scripting >>language >>that extends applications into web and mobile media. Attend the >>live webcast >>and join the prime developer group breaking into this new coding >>territory! >>http://sel.as-us.falkag.net/sel? >>cmd=lnk&kid=110944&bid=241720&dat=121642 >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by xPML, a groundbreaking scripting >>language >>that extends applications into web and mobile media. Attend the >>live webcast >>and join the prime developer group breaking into this new coding >>territory! >>http://sel.as-us.falkag.net/sel? >>cmd=lnk&kid=110944&bid=241720&dat=121642 >>_______________________________________________ >>Bodington-developers mailing list >>Bod...@li... >>https://lists.sourceforge.net/lists/listinfo/bodington-developers >> >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Bodington-developers mailing list >Bod...@li... >https://lists.sourceforge.net/lists/listinfo/bodington-developers > > > |