Community Forums

ATutor Bug Reports

bug (?) in course email


You must be signed-in to post.

AuthorSubject
 
Page: 1
vegard

Avatar for vegard
Subject: bug (?) in course emailQuote this post in your reply
hi,

I noticed that if you send an e-mail to "enrolled" users via the course e-mail, both enrolled and assistants gets the e-mail.

we've had sevaral complains about this, as some assistants gets mail that is only ment for students.

is this a bug? and how can we fix it?
Posted: 2007-09-10 04:41:17
IndieRect

Avatar for IndieRect
Subject: Re: bug (?) in course emailQuote this post in your reply
I guess it's rather a doubtful feature than a bug. Technically, the assistants are among those enrolled too. It seems that the question whether current behavior is right or wrong may have more than one answer.

It seems you could change /tools/course_email.php, making line 95 look like:
highlight_code('
$email_sql .= "C.approved='y' AND C.privileges = 0 OR ";')

I've NOT TESTED this, so verify it works first.
Posted: 2007-09-10 04:56:15
vegard

Avatar for vegard
Subject: Re: bug (?) in course emailQuote this post in your reply
thanks indie, I'll try that out tomorrow and post the results here!

you're probably right that it's not a bug, but I believe this should be changed anyway.

if enrolled is set to exclude assistants, that would give you more flexibility as you still could e-mail both groups, but also exclude assistants. In this case the language term should probably be changed to "enrolled (not assistants)" or similar, to avoid confusion.

what do you think, developers?
Posted: 2007-09-10 09:45:55
greg

Avatar for greg
Subject: Re: bug (?) in course emailQuote this post in your reply
I've added this to the feature tracker. We'll try to get it adjusted for the next release.
Posted: 2007-09-10 10:47:08
IndieRect

Avatar for IndieRect
Subject: Re: bug (?) in course emailQuote this post in your reply
An off-topic.

if enrolled is set to exclude assistants, that would give you more flexibility as you still could e-mail both groups, but also exclude assistants.


It has reminded me about my experience of using a Soviet programmable calculator Electronica MK-52. It was a good reliable machine with a reverse Polish notation, vast set of math, trig, stack, time, angle, logical, conditional, loop, memory management operations, EEPROM etc.
It had one strange peculiarity, though.

You know that one can easily get "x>0" by checking "x<=0" and acting on false. The same works for other pairs. So there would be enough 3 logical functions for any pair of numbers: =0, >0 and <0 (or !=0, <=0 and >=0).

This calculator could check even more conditions - four. They were: "x<0", "x=0", "x>=0" and "x!=0". Amazingly, you can see that such a redundancy number was, in fact, futile: for checking "x>0" condition one had to check "x>=0" and then "x!=0". That costs 2 more steps of a program (of 105 max).

Of course, the designers couldn't have missed this - more likely, such was a trade-off between expensive logical ICs and expensive memory ICs.

A photo of the calculator: upload.wikimedia.org/wikipedia/ru/6/60/Elektronika_mk_52.jpg . The operations described are written in yellow above the buttons of the second row.
Posted: 2007-09-10 10:48:54
vegard

Avatar for vegard
Subject: Re: bug (?) in course emailQuote this post in your reply
thanks Indie, worked like a charm! smile
Posted: 2007-09-11 06:57:26
IndieRect

Avatar for IndieRect
Subject: Re: bug (?) in course emailQuote this post in your reply
You're welcome, vegard.
Posted: 2007-09-11 07:14:26
 
Page: 1

You must be signed-in to post.

Related Articles