Menu
▾
▴
bodington-developers — Mailing list for Bodington developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
| 2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
| 2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Selwyn L. <sel...@ph...> - 2006-04-07 12:38:52
|
Sean et al, In a recent case with HEI 'xx' a project was not funded because of IP rights not being retained by the HEI. Despite our assertion that IP rights were vested in the community and furthermore HEI xx would still maintain the IP rights for their unique uses of the generic system, HEI xx seemed uniterested. We tried to explain that the content product such as a software based learning package could still be deemed 'theirs', so clearly there is much sentiment with in education to protect and exploit software based IP. I would say its understandable that indiviuals and individual HEI's, FEI's and even schools want to maintain their IP, perhaps even create commercial opportunities, so my concern is where the differences are between patentable system and copyrightable content... My own experience of UK patent law is most software is not patentable, particularly at the generic level. I imagine that most content is protectable and many will want to protect there software based learning packages. I would consider patenting system only to a. to protect against large commercial organisations exploiting the same or reverse engineered process and somehow blocking our own rights to use the technology by patenting first b. to protect the investment of a community The whole process of protecting intellectual property stifles creativity IMHO and should be avoided by those making and doing things :) life is to short, if your organisation can afford a person who enjoys this challenge pass it on to them on the other hand if I made a living purely from my creative outputs then I would want to be in an organisation that would protect them ethically. Cheers Sel Sean Mehan wrote: > Dear Bodders, > > I am part of a working party that has been trying to organize > opposition to upcoming proposed legislation aimed at implementing > prohibitive software patents that would hamper teaching and learning. > Please go > to http://flosse.dicole.org/?item=don-t-allow-software-patents-to-threaten-technology-enhanced-learning-in-europe > and read it, and if you agree that this would be a bad thing, consider > signing the petition. > > Thanks, > Sean Mehan > > > > > > Sean Mehan > > Head of e-Frameworks > > Learning and Information Services > > UHI - www.uhi.ac.uk <http://www.uhi.ac.uk> > > www.weblogs.uhi.ac.uk/sm00sm/ > > -------------------- > > GuanXi - a SAML/Shibboleth IdP, SP and Toolkit - > http://guanxi.sourceforge.net/ > > -------------------- > > Bodington - a Free VLE - http://bodington.sourceforge.net/ > > > |
|
From: Peter C. <Pet...@me...> - 2006-04-07 12:04:25
|
> From: Owen Davies > Anthony, I think you made a typo on that link because it's broken ;-) Should have been http://www.thedailywtf.com/ - Peter |
|
From: Owen D. <owe...@ou...> - 2006-04-07 12:02:00
|
better to use HSI - Hue, Saturation, Intensty (aka IHS or HSB - Hue, Saturation, Brightness). This colour space can be visualised as two cones sandwiched together at their bases. The apex of the bottom cone represents [I min] (black) and the apex of the top cone represents [I max] (white). The line connecting the two represents the greyscale values (I). At each point along this line, H is undefined and S is 0. When I is 0, the horizontal plane of the colour space is greatest, because this is the plane where the bases of both cones meet. Therefore, S max is greater on this plane than anyhwere else in the colour space, thus the most vibrant colours are on this plane. Conversely, as you tend towards full brightness or minimum brightness, S max is reduced, until it eventually reaches 0. This means that as colours become lighter or darker, they automatically become less saturated. Furthermore, Jon's initial gripe with S does not apply, because adjusting saturation has no impact on H or I. This is a much more intutive way of representing colour than HSV. You simply think of it as a slider for brightness, a slider for saturation and one for hue, with brightness being the only variable that alters either of the other two (namely saturation). The Java Advanced Imageing (JAI) API has a class called IHSColorSpace (http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/IHSColorSpace.html) which conveniently manages colour space transformation from/to RGB. btw, microsoft and CSS3 use the HSI colour space. apple use HSV. Photoshop etc. use both. Anthony, I think you made a typo on that link because it's broken ;-) owen ----- Original Message ----- From: "Antony Corfield" <an...@sm...> To: <bod...@li...> Sent: Friday, April 07, 2006 11:04 AM Subject: Re: [Bodington-developers] CSS Processing > We will be holding a 3 day seminar in HSV processing here in late June - > to register, click on the link below: > http://www.whatthefeckishetalkingabout.com/ > > On 6 Apr 2006, at 19:37, Jon Maber wrote: > >> I must bow to your superior mathologicity. >> >> Many thanks for taking on this work package, good luck..... >> >> Jon >> >> Sean Mehan wrote: >> >>> Yes, all fine Jon, BUT what about compliance with the critical and >>> well known Hausdorff's Metric Top, you know: >>> >>> Let (S,d) be a metric space, and let X be the collection of all >>> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by >>> f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g >>> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g (B,A)}. >>> You must concern yourself with (X, delta)! Your method clearly fails >>> here! Pah! >>> >>> And for anyone wanting to quibble with my counterexample, yes, I know, >>> but I couldn't write the vector cross product adequately in this crap >>> test format, so had to resort to *. >>> >>> -s >>> >>> >>> On 6 Apr 2006, at 18:59, Jon Maber wrote: >>> >>>> Nearly all user colour preference work will operate in Hue- >>>> Saturation-Value space, not Red-Green-Blue space. However, the >>>> standard Java HSV colour space (which Bodington currently uses) is >>>> not very good so I've devised a better method. (Probably reinvented >>>> but it only took a couple of days work.) The standard HSV space is >>>> cylindrical where H is the perpendicular distance from the axis to >>>> the colour point, H is the angle of that line from the red plane and >>>> V is the distance up the cylinder. All of the bottom face is black. >>>> (which means that if V=0 then the colour is black regardless of the >>>> values of H or S) However, the top face has white only at the center >>>> and has bright rainbow colours around the edge. This means that if V >>>> is non-zero, V and H are kept constant and S is varied then not only >>>> does the perceived saturation change but the brightness does too. The >>>> method used to map the cube rgb space onto the cylinder is also dodgy >>>> since for certain values of H changing S distorts the perceived hue. >>>> >>>> My method also maps to a cylinder but the top face of the cylinder is >>>> completely white. This means that V==100% always produces white no >>>> matter what the value of H or S. It also means that if H and V are >>>> kept constant and S is varied, the perceived brightness and hue keep >>>> constant. This is acheived by two rotations of the rgb cube so that >>>> the white to black vector lines up with the z axis. Then the shape is >>>> distorted so that vectors which run from the z axis to the cube >>>> surface and which lie parallel to the x,y plane are stretched >>>> uniformly to unit length. The resulting cylinder is squashed down >>>> the z axis to unit length. >>> >>> >>> >> >> >> >> ------------------------------------------------------- >> 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 |
|
From: Sean M. <se...@sm...> - 2006-04-07 10:12:57
|
Dear Bodders, I am part of a working party that has been trying to organize opposition to upcoming proposed legislation aimed at implementing prohibitive software patents that would hamper teaching and learning. Please go to http://flosse.dicole.org/?item=don-t-allow-software- patents-to-threaten-technology-enhanced-learning-in-europe and read it, and if you agree that this would be a bad thing, consider signing the petition. Thanks, Sean Mehan Sean Mehan Head of e-Frameworks Learning and Information Services UHI - www.uhi.ac.uk www.weblogs.uhi.ac.uk/sm00sm/ -------------------- GuanXi - a SAML/Shibboleth IdP, SP and Toolkit - http:// guanxi.sourceforge.net/ -------------------- Bodington - a Free VLE - http://bodington.sourceforge.net/ |
|
From: Antony C. <an...@sm...> - 2006-04-07 10:05:17
|
We will be holding a 3 day seminar in HSV processing here in late June - to register, click on the link below: http://www.whatthefeckishetalkingabout.com/ On 6 Apr 2006, at 19:37, Jon Maber wrote: > I must bow to your superior mathologicity. > > Many thanks for taking on this work package, good luck..... > > Jon > > Sean Mehan wrote: > >> Yes, all fine Jon, BUT what about compliance with the critical and >> well known Hausdorff's Metric Top, you know: >> >> Let (S,d) be a metric space, and let X be the collection of all >> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by >> f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g >> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g >> (B,A)}. You must concern yourself with (X, delta)! Your method >> clearly fails here! Pah! >> >> And for anyone wanting to quibble with my counterexample, yes, I >> know, but I couldn't write the vector cross product adequately in >> this crap test format, so had to resort to *. >> >> -s >> >> >> On 6 Apr 2006, at 18:59, Jon Maber wrote: >> >>> Nearly all user colour preference work will operate in Hue- >>> Saturation-Value space, not Red-Green-Blue space. However, the >>> standard Java HSV colour space (which Bodington currently uses) is >>> not very good so I've devised a better method. (Probably reinvented >>> but it only took a couple of days work.) The standard HSV space is >>> cylindrical where H is the perpendicular distance from the axis to >>> the colour point, H is the angle of that line from the red plane >>> and V is the distance up the cylinder. All of the bottom face is >>> black. (which means that if V=0 then the colour is black regardless >>> of the values of H or S) However, the top face has white only at >>> the center and has bright rainbow colours around the edge. This >>> means that if V is non-zero, V and H are kept constant and S is >>> varied then not only does the perceived saturation change but the >>> brightness does too. The method used to map the cube rgb space onto >>> the cylinder is also dodgy since for certain values of H changing S >>> distorts the perceived hue. >>> >>> My method also maps to a cylinder but the top face of the cylinder >>> is completely white. This means that V==100% always produces white >>> no matter what the value of H or S. It also means that if H and V >>> are kept constant and S is varied, the perceived brightness and hue >>> keep constant. This is acheived by two rotations of the rgb cube so >>> that the white to black vector lines up with the z axis. Then the >>> shape is distorted so that vectors which run from the z axis to the >>> cube surface and which lie parallel to the x,y plane are stretched >>> uniformly to unit length. The resulting cylinder is squashed down >>> the z axis to unit length. >> >> >> > > > > ------------------------------------------------------- > 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 |
|
From: Alistair Y. <ali...@sm...> - 2006-04-06 19:57:21
|
> 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 > |
|
From: Jon M. <jo...@te...> - 2006-04-06 19:45:38
|
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. |
|
From: Alistair Y. <ali...@sm...> - 2006-04-06 19:13:51
|
> 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 > |
|
From: Jon M. <jo...@te...> - 2006-04-06 18:37:41
|
I must bow to your superior mathologicity.
Many thanks for taking on this work package, good luck.....
Jon
Sean Mehan wrote:
> Yes, all fine Jon, BUT what about compliance with the critical and
> well known Hausdorff's Metric Top, you know:
>
> Let (S,d) be a metric space, and let X be the collection of all
> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by
> f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g
> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g
> (B,A)}. You must concern yourself with (X, delta)! Your method
> clearly fails here! Pah!
>
> And for anyone wanting to quibble with my counterexample, yes, I
> know, but I couldn't write the vector cross product adequately in
> this crap test format, so had to resort to *.
>
> -s
>
>
> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>
>> Nearly all user colour preference work will operate in Hue-
>> Saturation-Value space, not Red-Green-Blue space. However, the
>> standard Java HSV colour space (which Bodington currently uses) is
>> not very good so I've devised a better method. (Probably reinvented
>> but it only took a couple of days work.) The standard HSV space is
>> cylindrical where H is the perpendicular distance from the axis to
>> the colour point, H is the angle of that line from the red plane and
>> V is the distance up the cylinder. All of the bottom face is black.
>> (which means that if V=0 then the colour is black regardless of the
>> values of H or S) However, the top face has white only at the center
>> and has bright rainbow colours around the edge. This means that if
>> V is non-zero, V and H are kept constant and S is varied then not
>> only does the perceived saturation change but the brightness does
>> too. The method used to map the cube rgb space onto the cylinder is
>> also dodgy since for certain values of H changing S distorts the
>> perceived hue.
>>
>> My method also maps to a cylinder but the top face of the cylinder
>> is completely white. This means that V==100% always produces white
>> no matter what the value of H or S. It also means that if H and V
>> are kept constant and S is varied, the perceived brightness and hue
>> keep constant. This is acheived by two rotations of the rgb cube so
>> that the white to black vector lines up with the z axis. Then the
>> shape is distorted so that vectors which run from the z axis to the
>> cube surface and which lie parallel to the x,y plane are stretched
>> uniformly to unit length. The resulting cylinder is squashed down
>> the z axis to unit length.
>
>
>
|
|
From: Jon M. <jo...@te...> - 2006-04-06 18:34:16
|
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. > > > |
|
From: Sean M. <se...@sm...> - 2006-04-06 18:22:53
|
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!) |
|
From: Sean M. <se...@sm...> - 2006-04-06 18:20:19
|
Yes, all fine Jon, BUT what about compliance with the critical and
well known Hausdorff's Metric Top, you know:
Let (S,d) be a metric space, and let X be the collection of all
nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by
f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g
(A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g
(B,A)}. You must concern yourself with (X, delta)! Your method
clearly fails here! Pah!
And for anyone wanting to quibble with my counterexample, yes, I
know, but I couldn't write the vector cross product adequately in
this crap test format, so had to resort to *.
-s
On 6 Apr 2006, at 18:59, Jon Maber wrote:
> Nearly all user colour preference work will operate in Hue-
> Saturation-Value space, not Red-Green-Blue space. However, the
> standard Java HSV colour space (which Bodington currently uses) is
> not very good so I've devised a better method. (Probably reinvented
> but it only took a couple of days work.) The standard HSV space is
> cylindrical where H is the perpendicular distance from the axis to
> the colour point, H is the angle of that line from the red plane
> and V is the distance up the cylinder. All of the bottom face is
> black. (which means that if V=0 then the colour is black regardless
> of the values of H or S) However, the top face has white only at
> the center and has bright rainbow colours around the edge. This
> means that if V is non-zero, V and H are kept constant and S is
> varied then not only does the perceived saturation change but the
> brightness does too. The method used to map the cube rgb space onto
> the cylinder is also dodgy since for certain values of H changing S
> distorts the perceived hue.
>
> My method also maps to a cylinder but the top face of the cylinder
> is completely white. This means that V==100% always produces white
> no matter what the value of H or S. It also means that if H and V
> are kept constant and S is varied, the perceived brightness and hue
> keep constant. This is acheived by two rotations of the rgb cube so
> that the white to black vector lines up with the z axis. Then the
> shape is distorted so that vectors which run from the z axis to the
> cube surface and which lie parallel to the x,y plane are stretched
> uniformly to unit length. The resulting cylinder is squashed down
> the z axis to unit length.
|
|
From: Alistair Y. <ali...@sm...> - 2006-04-06 18:07:36
|
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 > |
|
From: Jon M. <jo...@te...> - 2006-04-06 17:59:15
|
Comments on this welcome.... O.K. I've now got straight in my mind how to do the CSS stuff that I'm planning (for my own web site initally). It depends on XSLT 2.0 because the transforms need to do some maths and 2.0 allows you to define functions in the stylesheet thus avoiding the need for call outs to a potentially less portable code library. (Most important if a binary, i.e. non-Java transformer is preferred.) I'm testing with Saxon. The process involves three different roles; designer, author, viewer. The designer is the person who designs the web site and is knowledgable about CSS. The designer creates the basic structure of documents and tools but doesn't deal with aesthetics such as specific colour schemes. The author is the creator and owner of documents created with tools provided by the designer who is allowed to change the appearance of their own or their group's documents and tools as seen by others within parameters defined by the designer. The viewer can navigate through the documents of various authors and has options to alter the appearance for the purposes of accessibility and preference. The alterations will always attempt to preserve the essential differences between one author's documents and another's. The web server will map *.css onto a url to a CGI script or servlet passing in the original path to the referenced css file. The script will find the original css file and a number of other files in a special sub-directory. In the special sub directory there may be a processed css file which is up to date. If that file is up-to-date it will be sent in place of the original css file. If it isn't up to date processing may be required to recreate the processed css file. Step 0) The designer creates one or more files that resemble standard CSS files. (Called designer CSS files.) This is an optional step for designers who can't cope with XML files and will require some non-standard extensions to the CSS format to implement extra functionality. (explained in the next step.) Step 1) An XML style file will represent what is essentially the designer CSS file but in a format that can be processed by XSLT. In addition to the normal content there will be a section that declares variables and the value part of any CSS declaration may be either a constant or reference a variable. (Variable declarations will have default values.) The decision about whether to put a constant or a variable depends on the designer's wish to give the document author parameters which they can use to change the appearance of their documents. It is likely that colours will be added as variables, some font properties will be added as variables but dimensions are more likely to be constants. (Ideally it will also be possible to put arithmetic expressions in but that will have to wait for version 2.) This file is called the designer xml style file and it will only be generated if it is older than the designer css file. Step 2) The author xml style file is generated by XSLT. (Only if it doesn't yet exist or is older than the designer xml style file.) The XSLT file that does the work is passed an author data file as a parameter. The author data file is a simple XML file that names variables and defines values. It may only contain a foreground and background color for example. The transform substitutes variable values into the style declarations of the author xml style file. If the author data file lacks a definition for a particular variable then the default value is used. Outside the scope of the servlet/cgi script is the creation and editing of the author data file - however the designer xml style file lists all the variables and will have descriptions of them (in multiple languages) so another application can present a form to users where they can choose colors etc. The number of these files generated = (num. css files) * (num. different authoring areas) Step 3) The user xml style file is genereated by XSLT. (Only if it doesn't yet exist or is older than the author xml style file.) The XSLT file that does the work is passed a user preference file as a parameter. The user preference file is XML that describes things like colour preferences, preferences for line spacing etc. etc. The transform looks at whole blocks of style, picking out specific declarations of interest and uses appropriate maths to bring the style sheet within constraints defined by the user's preferences while attempting to retain whatever individuality of the design it can. The number of these files potentially generated = (num. css files) * (num. different authoring areas) * (num. users with preferences) Users with default preferences are treated as a single user. Step 4) The user css style file is generated by XSLT. (Only if it doesn't exist or is older than the user xml style file.) I My estimate is that a native code XSLT processor invoked from CGI can do all of the above in less than 250ms. A Java XSLT processor invoked from a Servlet will probably be faster since it's permanently loaded in memory and ready to run. RGB to CSV ========= Nearly all user colour preference work will operate in Hue-Saturation-Value space, not Red-Green-Blue space. However, the standard Java HSV colour space (which Bodington currently uses) is not very good so I've devised a better method. (Probably reinvented but it only took a couple of days work.) The standard HSV space is cylindrical where H is the perpendicular distance from the axis to the colour point, H is the angle of that line from the red plane and V is the distance up the cylinder. All of the bottom face is black. (which means that if V=0 then the colour is black regardless of the values of H or S) However, the top face has white only at the center and has bright rainbow colours around the edge. This means that if V is non-zero, V and H are kept constant and S is varied then not only does the perceived saturation change but the brightness does too. The method used to map the cube rgb space onto the cylinder is also dodgy since for certain values of H changing S distorts the perceived hue. My method also maps to a cylinder but the top face of the cylinder is completely white. This means that V==100% always produces white no matter what the value of H or S. It also means that if H and V are kept constant and S is varied, the perceived brightness and hue keep constant. This is acheived by two rotations of the rgb cube so that the white to black vector lines up with the z axis. Then the shape is distorted so that vectors which run from the z axis to the cube surface and which lie parallel to the x,y plane are stretched uniformly to unit length. The resulting cylinder is squashed down the z axis to unit length. Jon |
|
From: Sean M. <se...@sm...> - 2006-04-06 16:23:57
|
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 > |
|
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 > > > |
|
From: Andrew B. <a.g...@le...> - 2006-04-06 16:18:47
|
Mike I've just upgraded a test server from 2.4 (ish) to 2.7(ish). It went OK, but you must remember - as soon as you have upgraded, stop Bodington and then stop and restart the database manager. Otherwise, you may end up like Atif and me, spending all afternoon chasing a 'bug' that turned out to be caused by the database caching the old version - doh! Aggie -----Original Message----- From: bod...@li... [mailto:bod...@li...] On Behalf Of M Thomas Sent: 06 April 2006 16:54 To: bod...@li... Subject: [Bodington-developers] Any issues when moving from 2.4.x to 2.6.x Hi everyone, I'm looking to upgrade the Leeds installation of Bodington from version 2.4.x to 2.6.x, I'm having a test run next week. Are there any issues that I should be aware of? Or does the setupservlet sort out everything? Thanks in advance -- m.cha3l ------------------------------------------------------- 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=k&kid0944&bid$1720&dat1642 _______________________________________________ Bodington-developers mailing list Bod...@li... https://lists.sourceforge.net/lists/listinfo/bodington-developers |
|
From: Peter C. <Pet...@me...> - 2006-04-06 16:16:17
|
> From: Matthew Buckett > If you upgrade to 2.6.0 then you should be ok, I never=20 > saw a fix for upgrading IMSCP so trying to run HEAD probably wouldn't=20 > work very well. 2.6.0 does not include upgrading the metadata for the new IMS content package support. At the very least I'd recommend replacing the 2.6 upgrade script with the one on HEAD, which allegedly does - Antony was testing it at UHI, but I never got any feedback. - Peter |
|
From: Matthew B. <mat...@ou...> - 2006-04-06 16:12:24
|
M Thomas wrote: > Hi everyone, > > I'm looking to upgrade the Leeds installation of Bodington from > version 2.4.x to 2.6.x, I'm having a test run next week. Good luck. Let us know how it goes. > Are there any issues that I should be aware of? Or does the > setupservlet sort out everything? It's designed to fix everything but it has never really been tested on a large deployment. If you upgrade to 2.6.0 then you should be ok, I never saw a fix for upgrading IMSCP so trying to run HEAD probably wouldn't work very well. Don't you run a custom build at Leeds? -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
|
From: Colin T. <col...@ou...> - 2006-04-06 16:12:06
|
M Thomas wrote: > I'm looking to upgrade the Leeds installation of Bodington from > version 2.4.x to 2.6.x, I'm having a test run next week. > > Are there any issues that I should be aware of? We had a problem with the metadata being rebuilt (upgrading from an earlier version that you are). You might already have up to date versions of the tables. Colin -- ____________________________________ Colin Tatham VLE Team Oxford University Computing Services http://www.oucs.ox.ac.uk/ltg/vle/ http://bodington.org |
|
From: M T. <m....@gm...> - 2006-04-06 16:01:27
|
Hi everyone, I'm looking to upgrade the Leeds installation of Bodington from version 2.4.x to 2.6.x, I'm having a test run next week. Are there any issues that I should be aware of? Or does the setupservlet sort out everything? Thanks in advance -- m.cha3l |
|
From: Paul D. <pau...@ou...> - 2006-04-06 15:03:17
|
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 |
|
From: Paul D. <pau...@ou...> - 2006-04-06 14:56:15
|
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 |
|
From: Sean M. <se...@sm...> - 2006-04-06 14:42:34
|
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 > |
|
From: Sean M. <se...@sm...> - 2006-04-06 14:28:19
|
yup. no doubt. We are going through a couple days of testing with what is on head just now, so by Tuesday there should be some feedback to assist in squashing those pesky bugs. Can someone at teach site provide a list of what they have written to head? ta s On 6 Apr 2006, at 15:07, Colin Tatham wrote: > We're pretty much heads down getting a new WebLearn version tested > for release on Tuesday. There are quite a few things that need > fixing/tweaking/testing on Bod HEAD, so I feel a release may still > be a way off... |
19 messages has been excluded from this view by a project administrator.
