bodington-developers

[Bodington-developers] Group email

[Antony C. <an...@sm...>]

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

RE: [Bodington-developers] Group email

[Paul D. <pau...@ou...>]

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

Re: [Bodington-developers] Group email

[Alistair Y. <ali...@sm...>]

I don't think you could construe this as "releasing" email addresses  
Paul. The emails are never displayed. When the tool does it's work,  
it gets them dynamically.

Alistair


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

RE: [Bodington-developers] Group email

[Paul D. <pau...@ou...>]

We're currently in discussion with our Data registration officer regarding
details gathered of users and how it is used.  I can just imagine some
stuffy academic type saying "I did not give you permission to email me on
this address".  Whether the person sending the mail sees the addresses or
not, you have released email addresses from the system to allow this to
happen.  Can you restrict it so only staff can email students, what rights
are required to send an email?

Snip from legal advice re access logs:
from a data protection point of view people must be informed when they use
the service that their personal information is being collected, what it will
be used for, whether it will be passed on to third parties etc. It needs to
be made clear at the login stage what information is being tracked, for what
purpose, and who will have access to the logs, so that people can then make
an informed choice about whether or not they wish to use the service.

Where we gather email addresses we mention only that it will be used for
notifications, so we'd need to either allow global signup, or else carry
separate email fields for notifications and this group mailer facility.  

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
Alistair Young
Sent: 06 April 2006 15:26
To: bod...@li...
Subject: Re: [Bodington-developers] Group email

I don't think you could construe this as "releasing" email addresses  
Paul. The emails are never displayed. When the tool does it's work,  
it gets them dynamically.

Alistair


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

Re: [Bodington-developers] Group email

[Sean M. <se...@sm...>]

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
>

RE: [Bodington-developers] Group email

[Paul D. <pau...@ou...>]

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

Re: [Bodington-developers] Group email

[Jon M. <jo...@te...>]

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
>
>  
>

Re: [Bodington-developers] Group email

[Alistair Y. <ali...@sm...>]

I think we can put to rest any fears on the publishing of email addresses=
.
That doesn't happen and you can't find out about high risk groups using
this tool. You only see the groups you're in. Whether that functionality
exposes holes in institutional process is another thing entirely... (I
never knew I was in *that* group!)

> remove themselves from the group
can you explain a bit more Jon? Do you mean something like a new group
associated with a real group? e.g. MOD101 (real group) + MOD101EMAIL
(email group for MOD101). A user can't remove themselves from MOD101 -
that's their course. They would join/leave MOD101EMAIL though.

Then again should they be allowed to opt out? How does a tutor contact
their students if they've all opted out of MOD101EMAIL? What does the
tutor do when they all fail due to lack of communication?

The approach Naomi has taken is to prefix the email with the appropriate
marker, e.g. [MOD101] and students are encouraged to learn to use their
email tool of choice to manage those emails. A simple rule to bin all
[MOD101] emails solves their problem.

There is documentation on how to use the email tool of choice as it's the
institutional one. They don't get mailed on their hotmail etc.

If someone is sending large amounts of unsolicited mail using the group
mailer then surely that's a job for the abuse of system squad?

I think the chat system we're implementing in CLAN will allow users to
blab as much as they want and leave the group mailer for academic use.

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

> 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. Th=
e
> '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 accoun=
t
> 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 transactio=
n
> 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 bul=
k
> 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 a=
re
>>different inside and outside the university - we have considerable
>> external
>>presence in the VLE.  Any system like this would need to take account o=
f
>>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=3D" +
>>>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=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>>_______________________________________________
>>>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=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>>>_______________________________________________
>>>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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
>>_______________________________________________
>>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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
>>_______________________________________________
>>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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Group email

[Sean M. <se...@sm...>]

You can of course find out about high risk groups if you are in such  
a high risk group, which means that you were high risk to begin with.

As al says, it is all about institutional group management, not the  
tool.....


ahh, the joys of institutional and enterprise....

s


On 6 Apr 2006, at 19:07, Alistair Young wrote:

> I think we can put to rest any fears on the publishing of email  
> addresses.
> That doesn't happen and you can't find out about high risk groups  
> using
> this tool. You only see the groups you're in. Whether that  
> functionality
> exposes holes in institutional process is another thing entirely... (I
> never knew I was in *that* group!)

Re: [Bodington-developers] Group email

[Jon M. <jo...@te...>]

There's abuse and then there's abuse....
If we are talking about the students then I think most organisations 
would be happy not to give them the option to opt in or opt out of the 
Emails. If a student is accidentally enrolled on a module and shouldn't 
be and they get annoyed by lots of irrelevant emails then they can 
always complain and get un-enrolled from the module.  It's probably 
better that they can't opt out of the email to give them another good 
reason to sort out their enrollments.

However, consider the following scenario.....

Miss Junior the teaching assistant manages a course module and wants 
notification emails to go out to all the enrolled students and all the 
lecturing staff.  Now Prof. Crusty starts getting emails from something 
called WebLearn that they've never heard of.  In some organisations it's 
made clear to Prof. Crusty that he has teaching duties and is expected 
to engage in student support and since he doesn't manage the module he 
has to participate in a way that is decided by a more junior member of 
staff......
....and in other organisations Prof. Crusty gets together with Prof. 
Pure-Research and they devise a policy whereby senior members of staff 
can opt out of irritating Emails about teaching from people like Miss 
Junior.

So, if Prof. Crusty and Prof Pure-Research get their way and choose to 
opt out of all bulk email from all course areas they can ask their 
secretaries to log in with their user names and passwords add them to a 
special group;

myuniversity.bulkemail_optout

Then the tool that sends out the emails will first list the users in the 
relevant group(s) and before sending the email will check that the user 
is NOT in the optout group.


Either way wouldn't it be a good idea for users to have a personal 
messaging tool within Bodington? They could choose to have all messages 
forwarded to their Email account but also access them on-line.  The 
On-line tool could allow person to person messaging.

Jon





Alistair Young wrote:

>I think we can put to rest any fears on the publishing of email addresses.
>That doesn't happen and you can't find out about high risk groups using
>this tool. You only see the groups you're in. Whether that functionality
>exposes holes in institutional process is another thing entirely... (I
>never knew I was in *that* group!)
>
>  
>
>>remove themselves from the group
>>    
>>
>can you explain a bit more Jon? Do you mean something like a new group
>associated with a real group? e.g. MOD101 (real group) + MOD101EMAIL
>(email group for MOD101). A user can't remove themselves from MOD101 -
>that's their course. They would join/leave MOD101EMAIL though.
>
>Then again should they be allowed to opt out? How does a tutor contact
>their students if they've all opted out of MOD101EMAIL? What does the
>tutor do when they all fail due to lack of communication?
>
>The approach Naomi has taken is to prefix the email with the appropriate
>marker, e.g. [MOD101] and students are encouraged to learn to use their
>email tool of choice to manage those emails. A simple rule to bin all
>[MOD101] emails solves their problem.
>
>There is documentation on how to use the email tool of choice as it's the
>institutional one. They don't get mailed on their hotmail etc.
>
>If someone is sending large amounts of unsolicited mail using the group
>mailer then surely that's a job for the abuse of system squad?
>
>I think the chat system we're implementing in CLAN will allow users to
>blab as much as they want and leave the group mailer for academic use.
>
>  
>

Re: [Bodington-developers] Group email

[Alistair Y. <ali...@sm...>]

> Prof. Crusty starts getting emails from something
> called WebLearn
no, the group tool sends emails as the user. They'll get an email from
"Joe Bloggs", rather than the system.

> participate in a way that is decided by a more junior member of
> staff
email divert - back to using the email tool of choice properly. The email=
s
are marked [MOD101].

> senior members of staff
> can opt out of irritating Emails
ok. I wonder what they do if they don't want to converse with their
students though.

> secretaries to log in with their user names and passwords
well we won't go there. Just coz it happens doesn't mean we support
extremely bad practice. I'm sure people like the Athens service providers
would be keen to hear about people like that - and block them!

> myuniversity.bulkemail_optout
an idea, yes. Have a bin full of people who for some reason or other call
themselves tutors but don't want communication from students. Could
probably provide a tool for this for staff use in their user preferences
page.

> will check that the user
> is NOT in the optout group
yep

> Either way wouldn't it be a good idea for users to have a personal
> messaging tool within Bodington?
IMHO no. Why reinvent outlook in bod? I'm coming from a purely resource
perspective though. If someone wants to get funding...

> The On-line tool could allow person to person messaging
It does that anyway via their email settings in bod. It lets you select
individual users as well as groups.

I think we're converging - it's just case of whether we should implement =
a
"sin bin" for the tool. I pool of "tutors" who don't want to be contacted=
!

Just out of interest - should the tool consult the bin before displaying
staff users that can be emailed? I suppose so. If the student emails a
staff member who doesn't want to know then they'll just phone the helpdes=
k
to see why they never got a reply.

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

> There's abuse and then there's abuse....
> If we are talking about the students then I think most organisations
> would be happy not to give them the option to opt in or opt out of the
> Emails. If a student is accidentally enrolled on a module and shouldn't
> be and they get annoyed by lots of irrelevant emails then they can
> always complain and get un-enrolled from the module.  It's probably
> better that they can't opt out of the email to give them another good
> reason to sort out their enrollments.
>
> However, consider the following scenario.....
>
> Miss Junior the teaching assistant manages a course module and wants
> notification emails to go out to all the enrolled students and all the
> lecturing staff.  Now Prof. Crusty starts getting emails from something
> called WebLearn that they've never heard of.  In some organisations it'=
s
> made clear to Prof. Crusty that he has teaching duties and is expected
> to engage in student support and since he doesn't manage the module he
> has to participate in a way that is decided by a more junior member of
> staff......
> ....and in other organisations Prof. Crusty gets together with Prof.
> Pure-Research and they devise a policy whereby senior members of staff
> can opt out of irritating Emails about teaching from people like Miss
> Junior.
>
> So, if Prof. Crusty and Prof Pure-Research get their way and choose to
> opt out of all bulk email from all course areas they can ask their
> secretaries to log in with their user names and passwords add them to a
> special group;
>
> myuniversity.bulkemail_optout
>
> Then the tool that sends out the emails will first list the users in th=
e
> relevant group(s) and before sending the email will check that the user
> is NOT in the optout group.
>
>
> Either way wouldn't it be a good idea for users to have a personal
> messaging tool within Bodington? They could choose to have all messages
> forwarded to their Email account but also access them on-line.  The
> On-line tool could allow person to person messaging.
>
> Jon
>
>
>
>
>
> Alistair Young wrote:
>
>>I think we can put to rest any fears on the publishing of email
>> addresses.
>>That doesn't happen and you can't find out about high risk groups using
>>this tool. You only see the groups you're in. Whether that functionalit=
y
>>exposes holes in institutional process is another thing entirely... (I
>>never knew I was in *that* group!)
>>
>>
>>
>>>remove themselves from the group
>>>
>>>
>>can you explain a bit more Jon? Do you mean something like a new group
>>associated with a real group? e.g. MOD101 (real group) + MOD101EMAIL
>>(email group for MOD101). A user can't remove themselves from MOD101 -
>>that's their course. They would join/leave MOD101EMAIL though.
>>
>>Then again should they be allowed to opt out? How does a tutor contact
>>their students if they've all opted out of MOD101EMAIL? What does the
>>tutor do when they all fail due to lack of communication?
>>
>>The approach Naomi has taken is to prefix the email with the appropriat=
e
>>marker, e.g. [MOD101] and students are encouraged to learn to use their
>>email tool of choice to manage those emails. A simple rule to bin all
>>[MOD101] emails solves their problem.
>>
>>There is documentation on how to use the email tool of choice as it's t=
he
>>institutional one. They don't get mailed on their hotmail etc.
>>
>>If someone is sending large amounts of unsolicited mail using the group
>>mailer then surely that's a job for the abuse of system squad?
>>
>>I think the chat system we're implementing in CLAN will allow users to
>>blab as much as they want and leave the group mailer for academic use.
>>
>>
>>
>
>
>
> -------------------------------------------------------
> 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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Group email

[Jon M. <jo...@te...>]

Alistair Young wrote:

>>Prof. Crusty starts getting emails from something
>>called WebLearn
>>    
>>
>no, the group tool sends emails as the user. They'll get an email from
>"Joe Bloggs", rather than the system.
>  
>
Neat! (I assume you don't allow users to set their own Email address - 
that would be a recipe for disaster. How do you enforce that?  At Leeds 
the mail would have to come from the help desk because users can put any 
email address they like against their account. Sysadmin config option?)

>>participate in a way that is decided by a more junior member of
>>staff
>>    
>>
>email divert - back to using the email tool of choice properly. The emails
>are marked [MOD101].
>  
>
Perfectly reasonable suggestion.  Would you like to Email Prof. Crusty 
and explain it to him?

>>senior members of staff
>>can opt out of irritating Emails
>>    
>>
>ok. I wonder what they do if they don't want to converse with their
>students though.
>  
>
Lock the office door and go quiet when they hear it knock.  Better still 
put the office the other side of a laboratory with lots of biohazard 
signs on the door and dangerous looking equipment inside.

>>secretaries to log in with their user names and passwords
>>    
>>
>well we won't go there. Just coz it happens doesn't mean we support
>extremely bad practice. I'm sure people like the Athens service providers
>would be keen to hear about people like that - and block them!
>  
>
The only thing you can really do with very senior staff is to devote 
masses of staff time to giving them a way to acheive what they want with 
even less personal effort than would be required to break the rules.

>>myuniversity.bulkemail_optout
>>    
>>
>an idea, yes. Have a bin full of people who for some reason or other call
>themselves tutors but don't want communication from students. Could
>probably provide a tool for this for staff use in their user preferences
>page.
>
>  
>
>>will check that the user
>>is NOT in the optout group
>>    
>>
>yep
>
>  
>
>>Either way wouldn't it be a good idea for users to have a personal
>>messaging tool within Bodington?
>>    
>>
>IMHO no. Why reinvent outlook in bod? I'm coming from a purely resource
>perspective though. If someone wants to get funding...
>  
>
Actually, now I think about it I agree.  The thing I really miss in 
Email clients that I've used is the ability to easily group together 
dialogues with specific people, including my replies regardless of the 
subject lines and even if one or other of the people didn't quote the 
other's text.  I.e. a sort which uses the 'from' field on other people's 
messages, the 'to' field on my messages and within chunks of messages 
to/from the same person, chronological. Acheiving anything like this 
involves a lot of fiddling about and you need to know what you are 
trying to acheive.  Something like this would be particularly useful for 
one to one tutoring. However, if you use a log book tool in Bodington, 
that's pretty much what you get.  I'd forgotten.

>>The On-line tool could allow person to person messaging
>>    
>>
>It does that anyway via their email settings in bod. It lets you select
>individual users as well as groups.
>  
>
Cool!

>I think we're converging - it's just case of whether we should implement a
>"sin bin" for the tool. I pool of "tutors" who don't want to be contacted!
>
>Just out of interest - should the tool consult the bin before displaying
>staff users that can be emailed? I suppose so. If the student emails a
>staff member who doesn't want to know then they'll just phone the helpdesk
>to see why they never got a reply.
>  
>
I would put the user's name with a big grumpy face icon, the text 'Prof. 
Crusty does not accept Emails sent from this tool and has told us not to 
reveal his Email address.' and a greyed out check box.

The interesting question is what do you do if Prof. Crusty will accept 
messages from his personal tutees but not from other students. Not 
something for your tool right now but I have some ideas about how to 
deal with this kind of question - it depends on users creating their own 
personal lists of users and assigning roles which indicate relationships 
with them. "My study circle", "My tutors" "My friends" "People who have 
sent me offensive messages and who I never want to message me again."

*********************************************************************************
While the character of Prof. Crusty is based on a real person he has 
been largely fictionalised for the purposes of this Email. Other 
character(s) may or may not be fictionalised amalgams of zero or more 
real or imaginary persons.

Re: [Bodington-developers] Group email

[Alistair Y. <ali...@sm...>]

> don't allow users to set their own Email address ... How do you enforce
that?
The LDAPAuthenticator creates their account when they first login and get=
s
their institutional email address from the SRS. We're planning to
implement IMS provisioning as doing it this way means tutors can't put
them in cohorts until they login.

> Would you like to Email Prof. Crusty
> and explain it to him?
LOL! certainly would, in no uncertain terms!
class ProfCrusty extends User - need I say more? ;)

> Lock the office door and go quiet when they hear it knock
damn, you've sussed me

> The only thing you can really do with very senior staff...
I bow to your superior knowledge on this Jon. They keep me away from
senior staff, for obvious reasons (see Prof Crusty) ;)

> I would put the user's name with a big grumpy face icon
ROTFL - did you get that Naomi - I can provide the grumpy face icon

> assigning roles which indicate relationships with them
hmmm... sounds a bit like rdf/ontology territory. I can hear the FC
stirring...

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

> Alistair Young wrote:
>
>>>Prof. Crusty starts getting emails from something
>>>called WebLearn
>>>
>>>
>>no, the group tool sends emails as the user. They'll get an email from
>>"Joe Bloggs", rather than the system.
>>
>>
> Neat! (I assume you don't allow users to set their own Email address -
> that would be a recipe for disaster. How do you enforce that?  At Leeds
> the mail would have to come from the help desk because users can put an=
y
> email address they like against their account. Sysadmin config option?)
>
>>>participate in a way that is decided by a more junior member of
>>>staff
>>>
>>>
>>email divert - back to using the email tool of choice properly. The
>> emails
>>are marked [MOD101].
>>
>>
> Perfectly reasonable suggestion.  Would you like to Email Prof. Crusty
> and explain it to him?
>
>>>senior members of staff
>>>can opt out of irritating Emails
>>>
>>>
>>ok. I wonder what they do if they don't want to converse with their
>>students though.
>>
>>
> Lock the office door and go quiet when they hear it knock.  Better stil=
l
> put the office the other side of a laboratory with lots of biohazard
> signs on the door and dangerous looking equipment inside.
>
>>>secretaries to log in with their user names and passwords
>>>
>>>
>>well we won't go there. Just coz it happens doesn't mean we support
>>extremely bad practice. I'm sure people like the Athens service provide=
rs
>>would be keen to hear about people like that - and block them!
>>
>>
> The only thing you can really do with very senior staff is to devote
> masses of staff time to giving them a way to acheive what they want wit=
h
> even less personal effort than would be required to break the rules.
>
>>>myuniversity.bulkemail_optout
>>>
>>>
>>an idea, yes. Have a bin full of people who for some reason or other ca=
ll
>>themselves tutors but don't want communication from students. Could
>>probably provide a tool for this for staff use in their user preference=
s
>>page.
>>
>>
>>
>>>will check that the user
>>>is NOT in the optout group
>>>
>>>
>>yep
>>
>>
>>
>>>Either way wouldn't it be a good idea for users to have a personal
>>>messaging tool within Bodington?
>>>
>>>
>>IMHO no. Why reinvent outlook in bod? I'm coming from a purely resource
>>perspective though. If someone wants to get funding...
>>
>>
> Actually, now I think about it I agree.  The thing I really miss in
> Email clients that I've used is the ability to easily group together
> dialogues with specific people, including my replies regardless of the
> subject lines and even if one or other of the people didn't quote the
> other's text.  I.e. a sort which uses the 'from' field on other people'=
s
> messages, the 'to' field on my messages and within chunks of messages
> to/from the same person, chronological. Acheiving anything like this
> involves a lot of fiddling about and you need to know what you are
> trying to acheive.  Something like this would be particularly useful fo=
r
> one to one tutoring. However, if you use a log book tool in Bodington,
> that's pretty much what you get.  I'd forgotten.
>
>>>The On-line tool could allow person to person messaging
>>>
>>>
>>It does that anyway via their email settings in bod. It lets you select
>>individual users as well as groups.
>>
>>
> Cool!
>
>>I think we're converging - it's just case of whether we should implemen=
t
>> a
>>"sin bin" for the tool. I pool of "tutors" who don't want to be
>> contacted!
>>
>>Just out of interest - should the tool consult the bin before displayin=
g
>>staff users that can be emailed? I suppose so. If the student emails a
>>staff member who doesn't want to know then they'll just phone the
>> helpdesk
>>to see why they never got a reply.
>>
>>
> I would put the user's name with a big grumpy face icon, the text 'Prof=
.
> Crusty does not accept Emails sent from this tool and has told us not t=
o
> reveal his Email address.' and a greyed out check box.
>
> The interesting question is what do you do if Prof. Crusty will accept
> messages from his personal tutees but not from other students. Not
> something for your tool right now but I have some ideas about how to
> deal with this kind of question - it depends on users creating their ow=
n
> personal lists of users and assigning roles which indicate relationship=
s
> with them. "My study circle", "My tutors" "My friends" "People who have
> sent me offensive messages and who I never want to message me again."
>
> ***********************************************************************=
**********
> While the character of Prof. Crusty is based on a real person he has
> been largely fictionalised for the purposes of this Email. Other
> character(s) may or may not be fictionalised amalgams of zero or more
> real or imaginary persons.
>
>
>
>
> -------------------------------------------------------
> 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=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Group email

[Sean M. <se...@sm...>]

ok, nice thread. But....


where are we with this? Is there desire to see this in head or not?
s



On 6 Apr 2006, at 20:57, Alistair Young wrote:

>> don't allow users to set their own Email address ... How do you =20
>> enforce
> that?
> The LDAPAuthenticator creates their account when they first login =20
> and gets
> their institutional email address from the SRS. We're planning to
> implement IMS provisioning as doing it this way means tutors can't put
> them in cohorts until they login.
>
>> Would you like to Email Prof. Crusty
>> and explain it to him?
> LOL! certainly would, in no uncertain terms!
> class ProfCrusty extends User - need I say more? ;)
>
>> Lock the office door and go quiet when they hear it knock
> damn, you've sussed me
>
>> The only thing you can really do with very senior staff...
> I bow to your superior knowledge on this Jon. They keep me away from
> senior staff, for obvious reasons (see Prof Crusty) ;)
>
>> I would put the user's name with a big grumpy face icon
> ROTFL - did you get that Naomi - I can provide the grumpy face icon
>
>> assigning roles which indicate relationships with them
> hmmm... sounds a bit like rdf/ontology territory. I can hear the FC
> stirring...
>
> --=20
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal M=F2r Ostaig
> Isle of Skye
> Scotland
>
>> Alistair Young wrote:
>>
>>>> Prof. Crusty starts getting emails from something
>>>> called WebLearn
>>>>
>>>>
>>> no, the group tool sends emails as the user. They'll get an email =20=

>>> from
>>> "Joe Bloggs", rather than the system.
>>>
>>>
>> Neat! (I assume you don't allow users to set their own Email =20
>> address -
>> that would be a recipe for disaster. How do you enforce that?  At =20
>> Leeds
>> the mail would have to come from the help desk because users can =20
>> put any
>> email address they like against their account. Sysadmin config =20
>> option?)
>>
>>>> participate in a way that is decided by a more junior member of
>>>> staff
>>>>
>>>>
>>> email divert - back to using the email tool of choice properly. The
>>> emails
>>> are marked [MOD101].
>>>
>>>
>> Perfectly reasonable suggestion.  Would you like to Email Prof. =20
>> Crusty
>> and explain it to him?
>>
>>>> senior members of staff
>>>> can opt out of irritating Emails
>>>>
>>>>
>>> ok. I wonder what they do if they don't want to converse with their
>>> students though.
>>>
>>>
>> Lock the office door and go quiet when they hear it knock.  Better =20=

>> still
>> put the office the other side of a laboratory with lots of biohazard
>> signs on the door and dangerous looking equipment inside.
>>
>>>> secretaries to log in with their user names and passwords
>>>>
>>>>
>>> well we won't go there. Just coz it happens doesn't mean we support
>>> extremely bad practice. I'm sure people like the Athens service =20
>>> providers
>>> would be keen to hear about people like that - and block them!
>>>
>>>
>> The only thing you can really do with very senior staff is to devote
>> masses of staff time to giving them a way to acheive what they =20
>> want with
>> even less personal effort than would be required to break the rules.
>>
>>>> myuniversity.bulkemail_optout
>>>>
>>>>
>>> an idea, yes. Have a bin full of people who for some reason or =20
>>> other call
>>> themselves tutors but don't want communication from students. Could
>>> probably provide a tool for this for staff use in their user =20
>>> preferences
>>> page.
>>>
>>>
>>>
>>>> will check that the user
>>>> is NOT in the optout group
>>>>
>>>>
>>> yep
>>>
>>>
>>>
>>>> Either way wouldn't it be a good idea for users to have a personal
>>>> messaging tool within Bodington?
>>>>
>>>>
>>> IMHO no. Why reinvent outlook in bod? I'm coming from a purely =20
>>> resource
>>> perspective though. If someone wants to get funding...
>>>
>>>
>> Actually, now I think about it I agree.  The thing I really miss in
>> Email clients that I've used is the ability to easily group together
>> dialogues with specific people, including my replies regardless of =20=

>> the
>> subject lines and even if one or other of the people didn't quote the
>> other's text.  I.e. a sort which uses the 'from' field on other =20
>> people's
>> messages, the 'to' field on my messages and within chunks of messages
>> to/from the same person, chronological. Acheiving anything like this
>> involves a lot of fiddling about and you need to know what you are
>> trying to acheive.  Something like this would be particularly =20
>> useful for
>> one to one tutoring. However, if you use a log book tool in =20
>> Bodington,
>> that's pretty much what you get.  I'd forgotten.
>>
>>>> The On-line tool could allow person to person messaging
>>>>
>>>>
>>> It does that anyway via their email settings in bod. It lets you =20
>>> select
>>> individual users as well as groups.
>>>
>>>
>> Cool!
>>
>>> I think we're converging - it's just case of whether we should =20
>>> implement
>>> a
>>> "sin bin" for the tool. I pool of "tutors" who don't want to be
>>> contacted!
>>>
>>> Just out of interest - should the tool consult the bin before =20
>>> displaying
>>> staff users that can be emailed? I suppose so. If the student =20
>>> emails a
>>> staff member who doesn't want to know then they'll just phone the
>>> helpdesk
>>> to see why they never got a reply.
>>>
>>>
>> I would put the user's name with a big grumpy face icon, the text =20
>> 'Prof.
>> Crusty does not accept Emails sent from this tool and has told us =20
>> not to
>> reveal his Email address.' and a greyed out check box.
>>
>> The interesting question is what do you do if Prof. Crusty will =20
>> accept
>> messages from his personal tutees but not from other students. Not
>> something for your tool right now but I have some ideas about how to
>> deal with this kind of question - it depends on users creating =20
>> their own
>> personal lists of users and assigning roles which indicate =20
>> relationships
>> with them. "My study circle", "My tutors" "My friends" "People who =20=

>> have
>> sent me offensive messages and who I never want to message me again."
>>
>> *********************************************************************=20=

>> ************
>> While the character of Prof. Crusty is based on a real person he has
>> been largely fictionalised for the purposes of this Email. Other
>> character(s) may or may not be fictionalised amalgams of zero or more
>> real or imaginary persons.
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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?=20
>> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
>> _______________________________________________
>> 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 =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Group email

[Sean M. <se...@sm...>]

Yeah, i can see what you have to do to keep your email secure, but I  
don't see how that impinges on this.

Try the i/f. You will see that nothing is displayed (no email values)  
and when it fires from there it becomes normal email.
You only get to email to groups of which you are a member. Again, it  
is not the tool, but institutional group management.


-s


On 6 Apr 2006, at 16:03, 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
>