Menu
▾
▴
Re: [Bodington-developers] Group email
|
From: Sean M. <se...@sm...> - 2006-04-07 21:14:13
|
ok, nice thread. But.... where are we with this? Is there desire to see this in head or not? s On 6 Apr 2006, at 20:57, Alistair Young wrote: >> don't allow users to set their own Email address ... How do you =20 >> enforce > that? > The LDAPAuthenticator creates their account when they first login =20 > and gets > their institutional email address from the SRS. We're planning to > implement IMS provisioning as doing it this way means tutors can't put > them in cohorts until they login. > >> Would you like to Email Prof. Crusty >> and explain it to him? > LOL! certainly would, in no uncertain terms! > class ProfCrusty extends User - need I say more? ;) > >> Lock the office door and go quiet when they hear it knock > damn, you've sussed me > >> The only thing you can really do with very senior staff... > I bow to your superior knowledge on this Jon. They keep me away from > senior staff, for obvious reasons (see Prof Crusty) ;) > >> I would put the user's name with a big grumpy face icon > ROTFL - did you get that Naomi - I can provide the grumpy face icon > >> assigning roles which indicate relationships with them > hmmm... sounds a bit like rdf/ontology territory. I can hear the FC > stirring... > > --=20 > Alistair Young > Senior Software Engineer > UHI@Sabhal M=F2r Ostaig > Isle of Skye > Scotland > >> Alistair Young wrote: >> >>>> Prof. Crusty starts getting emails from something >>>> called WebLearn >>>> >>>> >>> no, the group tool sends emails as the user. They'll get an email =20= >>> from >>> "Joe Bloggs", rather than the system. >>> >>> >> Neat! (I assume you don't allow users to set their own Email =20 >> address - >> that would be a recipe for disaster. How do you enforce that? At =20 >> Leeds >> the mail would have to come from the help desk because users can =20 >> put any >> email address they like against their account. Sysadmin config =20 >> option?) >> >>>> participate in a way that is decided by a more junior member of >>>> staff >>>> >>>> >>> email divert - back to using the email tool of choice properly. The >>> emails >>> are marked [MOD101]. >>> >>> >> Perfectly reasonable suggestion. Would you like to Email Prof. =20 >> Crusty >> and explain it to him? >> >>>> senior members of staff >>>> can opt out of irritating Emails >>>> >>>> >>> ok. I wonder what they do if they don't want to converse with their >>> students though. >>> >>> >> Lock the office door and go quiet when they hear it knock. Better =20= >> still >> put the office the other side of a laboratory with lots of biohazard >> signs on the door and dangerous looking equipment inside. >> >>>> secretaries to log in with their user names and passwords >>>> >>>> >>> well we won't go there. Just coz it happens doesn't mean we support >>> extremely bad practice. I'm sure people like the Athens service =20 >>> providers >>> would be keen to hear about people like that - and block them! >>> >>> >> The only thing you can really do with very senior staff is to devote >> masses of staff time to giving them a way to acheive what they =20 >> want with >> even less personal effort than would be required to break the rules. >> >>>> myuniversity.bulkemail_optout >>>> >>>> >>> an idea, yes. Have a bin full of people who for some reason or =20 >>> other call >>> themselves tutors but don't want communication from students. Could >>> probably provide a tool for this for staff use in their user =20 >>> preferences >>> page. >>> >>> >>> >>>> will check that the user >>>> is NOT in the optout group >>>> >>>> >>> yep >>> >>> >>> >>>> Either way wouldn't it be a good idea for users to have a personal >>>> messaging tool within Bodington? >>>> >>>> >>> IMHO no. Why reinvent outlook in bod? I'm coming from a purely =20 >>> resource >>> perspective though. If someone wants to get funding... >>> >>> >> Actually, now I think about it I agree. The thing I really miss in >> Email clients that I've used is the ability to easily group together >> dialogues with specific people, including my replies regardless of =20= >> the >> subject lines and even if one or other of the people didn't quote the >> other's text. I.e. a sort which uses the 'from' field on other =20 >> people's >> messages, the 'to' field on my messages and within chunks of messages >> to/from the same person, chronological. Acheiving anything like this >> involves a lot of fiddling about and you need to know what you are >> trying to acheive. Something like this would be particularly =20 >> useful for >> one to one tutoring. However, if you use a log book tool in =20 >> Bodington, >> that's pretty much what you get. I'd forgotten. >> >>>> The On-line tool could allow person to person messaging >>>> >>>> >>> It does that anyway via their email settings in bod. It lets you =20 >>> select >>> individual users as well as groups. >>> >>> >> Cool! >> >>> I think we're converging - it's just case of whether we should =20 >>> implement >>> a >>> "sin bin" for the tool. I pool of "tutors" who don't want to be >>> contacted! >>> >>> Just out of interest - should the tool consult the bin before =20 >>> displaying >>> staff users that can be emailed? I suppose so. If the student =20 >>> emails a >>> staff member who doesn't want to know then they'll just phone the >>> helpdesk >>> to see why they never got a reply. >>> >>> >> I would put the user's name with a big grumpy face icon, the text =20 >> 'Prof. >> Crusty does not accept Emails sent from this tool and has told us =20 >> not to >> reveal his Email address.' and a greyed out check box. >> >> The interesting question is what do you do if Prof. Crusty will =20 >> accept >> messages from his personal tutees but not from other students. Not >> something for your tool right now but I have some ideas about how to >> deal with this kind of question - it depends on users creating =20 >> their own >> personal lists of users and assigning roles which indicate =20 >> relationships >> with them. "My study circle", "My tutors" "My friends" "People who =20= >> have >> sent me offensive messages and who I never want to message me again." >> >> *********************************************************************=20= >> ************ >> While the character of Prof. Crusty is based on a real person he has >> been largely fictionalised for the purposes of this Email. Other >> character(s) may or may not be fictionalised amalgams of zero or more >> real or imaginary persons. >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting >> language >> that extends applications into web and mobile media. Attend the live >> webcast >> and join the prime developer group breaking into this new coding >> territory! >> http://sel.as-us.falkag.net/sel?=20 >> cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642 >> _______________________________________________ >> Bodington-developers mailing list >> Bod...@li... >> https://lists.sourceforge.net/lists/listinfo/bodington-developers >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
