I should have seen this coming... My Moodle site is in violation of our school district's policy which states the following:
The school's designated person for the web page should check all new pages or updates to make sure that:
-- no student's personal information appears on any pages.
such as their full name, class schedule, home address, telephone number, e-mail address, name(s) of family members;
-- no students photograph and name appear on the same page
What first occured to me as the simplest solution was to have students enter bogus information, but I cannot imagine keeping up with students' aliases.
Maybe the solution is to make this information visible only to teachers. I have e-mailed Martin about this already and he has started working on it.
These stipulations are quite common in schools around here and I imagine that other Moodlers will run into this problem.
What are your thoughts about this?
Let me get this straight: student info must be hidden from other students and school personnel? If that's the case, then this is an absurd policy.
If it has to be hidden just from outsiders, then the require_login() hack in the top moodle/index.php page discussed recently would address this issue.
Happy I live in Belgium 
We don't have that problem over here. I don't place pictures of my students in the profile: they can place any picture they like (altough I would be happy if they did publish there foto: it's easier to learn names)
Also my moodle-site is not verry "exposed". I think it's a legaly grey zone over here.
Can't it be sufficient if you close the site for free registrations? (altough my wife Ilse wouldn't like that idea , she's realy happy with your idea)
...altough my wife Ilse wouldn't like that idea , she's realy happy with your idea...
That's great! We managed to get into the lab for a few minutes today and post our first messages. Nothing very impressive, but it's a start. And we posted pictures of ourselves, too! (But, in light of the aforementioned policy, we did not indicate which names correspond to which faces.)
That's great! We managed to get into the lab for a few minutes today and post our first messages. Nothing very impressive, but it's a start. And we posted pictures of ourselves, too! (But, in light of the aforementioned policy, we did not indicate which names correspond to which faces.)
This same sort of restriction is also in effect for most US universities under the Family Education Rights and Privacy Act (FERPA) for Postsecondary Institutions.
However, the implication of FERPA for information a student puts on Moodle is actually a bit hazy. Clearly, an open public display of student informaiton (name, classes enrolled in, address, etc.) would be a big problem. But what information is given out to only other students in the same class becomes a bit trickier. An administrator with an eye toward "avoid all possibility of lawsuit" would be understandably jumpy about the information that might appear in a Moodle user profile, but on the other hand it's common practice for instructors to pass around class lists so that students who work together can have contact information to reach one another. And in that scenario, like in Moodle, the information made available is up to the discretion of the student and only gets released to class members.
What to do, what to do? Since the decision about this varies from institution, and often from instructor to instructor, it would be ideal if the"participant information" that is displayed to fellow participants could be configured by the instructor. For example, maybe an instructor wants none of that information available to other students. Or maybe an instructor is ok with having Moodle share email contacts for other students, but wants none of the phone or address information shared.
Just an idea...
Now if you want another really messy bind, consider universities that are very leery of any electronic interaction with students that isn't done with university resources. Being hyper-paranoid (and ok, I think daft) about FERPA issues, my institution recently made a policy where all email interaction with students (both on the professor's end and the student's end) must be done via the university email accounts. So that means I've had to make sure that Moodle emails through a univeristy email account and then require that students use their campus email addresses. Technically the policy doesn't mention web hosted locations, so I've not yet run into trouble that I host my own Moodle site on my own server, but it's most likely just a matter of time before I need to find a way to get Moodle running on a machine on campus, which won't be a fun negotiation with an IT staff that has invested so much $$$ in WebCT and isn't very supportive of helping with an alternative that highlights a bad decision on their part.
Grrrrr,
John
I know that such a restrictive policy must seem absurd to most folks out there, but I am not trying to change the policy, I am trying not to run afoul of it. I am pretty sure that I would not be able to get this changed if I wanted to; most parents in our community would probably support the policy if they were actually aware of it.
So... There must be a way for me to hide the information from everyone but the instructors. If I am to keep using Moodle -- and I certainly intend to do so -- I will have to work through this problem. (I can't help it, I am hooked. In fact, I want a Moodle T-shirt for Chanukah.)
I am sure that there is a solution. I just haven't found it yet.
So... There must be a way for me to hide the information from everyone but the instructors. If I am to keep using Moodle -- and I certainly intend to do so -- I will have to work through this problem. (I can't help it, I am hooked. In fact, I want a Moodle T-shirt for Chanukah.)
I am sure that there is a solution. I just haven't found it yet.
I like John's suggestion, I'd just like to add my ¢2:
- An additional "nick" field might be useful. The nick could then be made visible to other users, while the full name would be disclosed to the teacher only.
- John writes: the decision about this varies from institution, and often from instructor to instructor. Therefore, cascading "privacy settings" might be useful here. The settings would specify which of the personal data are to be shown to outsiders, which - to other students, and which - to the teacher(s). By "cascading" I mean that the admin could set sitewide defaults, which could then be overridden on the course level by the teacher.
I think that this will be a problem that anyone of us will be facing, sooner or later so it's a must to deal with it now...
Here are my first thoughts about how to solve it (none mutually excluding):
Will
Here are my first thoughts about how to solve it (none mutually excluding):
- Show the "username" by default. Show "Firstname Lastname (username)" to teachers.
- Show [Initial of firstname] + [lastname] or any combination like this to the public eye.
- Let the student upload (if they are below 13 year-old) whatever picture they want... Their super heros, etc... This help to memorize their names also... and allow them to express themselves.
- If allowed, let them upload two pictures, one of themselves and one to the public (the super hero perhaps)... The private will be shown to the teachers.
Will
I have a very good feeling about this. I think that maybe it won't be long before this problem is solved!
And it occurs to me, by the way, that this is probably the kind of online conversation/collaboration that makes Dr. Strauss at Syllabus.com kind of nervous. [May the claws of a thousand lobsters squeeze his tender bits.]
And it occurs to me, by the way, that this is probably the kind of online conversation/collaboration that makes Dr. Strauss at Syllabus.com kind of nervous. [May the claws of a thousand lobsters squeeze his tender bits.]
Could part of the answer be found in doing something related to THIS? (Adding conditional statements so that certain fields are visible only to instructors?)
OK, well, putting my feelings about this policy aside, we can solve this problem while also solving the "Hungarian naming problem".
Note also that pictures and URLs are voluntary, email addresses already have a privacy policy, and other personal information isn't shown to students - so these don't really need to be changed. For security I think it's not a good idea to expose usernames either.
So here's a plan that I think will cater to all needs without being too inefficient:
I'll create a function called fullname($user) that returns the full name of a student. There can be a new site-wide configuration value to control this, which lets you select between "firstname lastname" (default), "lastname firstname", "firstname", "lastname", "username", "language setting". If languge setting is chosen, then the string "fullnamedisplay" is called from the current language pack. eg:
Note also that pictures and URLs are voluntary, email addresses already have a privacy policy, and other personal information isn't shown to students - so these don't really need to be changed. For security I think it's not a good idea to expose usernames either.
So here's a plan that I think will cater to all needs without being too inefficient:
I'll create a function called fullname($user) that returns the full name of a student. There can be a new site-wide configuration value to control this, which lets you select between "firstname lastname" (default), "lastname firstname", "firstname", "lastname", "username", "language setting". If languge setting is chosen, then the string "fullnamedisplay" is called from the current language pack. eg:
$string['fullnamedisplay'] = "$a->firstname $a->lastname"; // en
$string['fullnamedisplay'] = "$a->lastname $a->firstname"; // hu
There could also be an override parameter, I suppose, so that teachers will always see the version from the current language pack.
This function gets called from all the files that print the name. Sound OK?
That sounds great, Martin. Thank you so much.
I am looking forward to this feature. I can only imagine how much time and effort it must take to program something like this and very much hope that others will benefit from it.
I hate to raise my hand but...
If language setting is chosen, I'll have a problem with the Author View frame... I have to pass the field names to the query and I can get them or asume them from all values but this one (using the global paramter).
Any idea?
If language setting is chosen, I'll have a problem with the Author View frame... I have to pass the field names to the query and I can get them or asume them from all values but this one (using the global paramter).
Any idea?
Perhaps I'll drop the username setting, so all you need to do is retreive firstname and lastname (as you are doing already), then call fullname when needed, passing the entry object:
(don't CONCAT them in the database)
echo fullname($entry);
(don't CONCAT them in the database)
I did it to retrieve only the records needed based on user request ("hook") so if s/he click on T, for instance, just retrieve those entries create by people that his/her firstname or lastname (based on sortkey) begins with the letter T...
I think it does not solve the problem yet...
Or am I missing something?
Will
I think it does not solve the problem yet...
Will
Ah, I see what you mean. Possibly if the site configuration says anything but "firstname lastname" or "lastname firstname" then just disable that whole "hook" feature, keeping a plain page-by-page browse ...? 
I think I get lost.
The hook parameter is very important... It contains what to look for depending on the mode: If mode is letter, then hook has the letter to look for, if mode is cat, then it contains the cat id to look for, and so on. It is not used only in the author view frame. It is used everywhere.
You meant to get ride of the alphabet in that frame? I don't really like it...
Let me try to makes this clear to myself:
This might solve this problem...
Will
The hook parameter is very important... It contains what to look for depending on the mode: If mode is letter, then hook has the letter to look for, if mode is cat, then it contains the cat id to look for, and so on. It is not used only in the author view frame. It is used everywhere.
You meant to get ride of the alphabet in that frame? I don't really like it...
Let me try to makes this clear to myself:
- We need a way to know the order of the first and lastname of a user...
- We need a way to hide the name and lastname from the public.
- We need this way to be flexible so it can be used in php and MySQL as well.
This might solve this problem...
Will
Sorry, I was only talking about the author frame, because that's where the hook refers to names ... in other places 'hook' refers to other things, yes?
For teachers everything will look as it presently does, no need to change anything. I was just thinking that if
I don't think a fully-functioning "browse by author" tab is that important for students in a school where authorship is devalued.
I'm moving this thread to the developer forum ...
For teachers everything will look as it presently does, no need to change anything. I was just thinking that if
- the current user is a student or guest, and
- the site setting for name is restricted to only one name
I don't think a fully-functioning "browse by author" tab is that important for students in a school where authorship is devalued.
I'm moving this thread to the developer forum ...
Hi Martin
As you know I run a Moodle site for a UK school and have similar security concerns as those expressed above.
An option to hide the real name of users would be great, but I still have a problem with:
........email addresses already have a privacy policy.........
As I understand it, the user makes this decision - I need an admin option to overide this decision for all students using the site - as things currently stand I have a duty to keep students email private. Since our younger students currently only use the site as guests (more security considerations), I don't want the whole site to have login only access.
Best wishes
Ray
As a quick hack so you're covered, you can run this SQL command now and then (via the phpmyadmin module or anything else) ... it disables email display for all existing users:
UPDATE user SET maildisplay = 0
Contact me if you want this done automatically on your site.
UPDATE user SET maildisplay = 0
Contact me if you want this done automatically on your site.
Worked like a charm.
Very helpful, because I was able to instantly hide the addresses of users who are not in my classes. Didn't have to bother the other teachers.
Thanks.
Very helpful, because I was able to instantly hide the addresses of users who are not in my classes. Didn't have to bother the other teachers.
Thanks.
I like that option too, Martin.
What also would work for me is the option to hide the "participants"-link for guests, becouse the email-adress is also shown to guests, even if the "Allow only other course members..."-option is selected. (Is this a bug ?)
I use a life-class with "access for guests without enrollmentkey" to promote e-learning and Moodle particularly among collegues from mine and other schools, but I'm not happy with the fact that the whole world can see the e-mailadress of my students.
Martin:
I've installed the mysql manager mod into my moodle admin file. what do I do to run the above SQL command to hide the mail disply?
Thom
I've installed the mysql manager mod into my moodle admin file. what do I do to run the above SQL command to hide the mail disply?
Thom
Nevermind; I figured it out! 
I also figured out that to turn it back on I reset it to "1". 
To run this automatically, is it a matter of somehow tying it into the cron?
To run this automatically, is it a matter of somehow tying it into the cron?
How can I hack the code which creates new accounts to default maildisplay to 0? Can I set all the options to pass 0 for the variable? I am setting up a site which will have external users and cannot have email addresses shown. Would it be better/easier to eliminate the participants link for non-admins? Thanks in advance for your assistance.
I know this is a really old thread, but ...
is the "SET maildisplay = 0" available as a Moodle admin setting in v1.3.1? I need to be able to do this, but I can't find it in the settings.
Thanks!
Dear Jill Kaminski
I don't think that it is included as a button or anything that easy to set all the students mail to be not displayed. But here is how I think you you do it. I just did the following on my system and nothing seems to have gone wrong. It seems quite a simple procedure. But since this is the first time I have used an SQL command, I cannot be 100% sure that this is okay.
- Down load MySQL ADMIN (which is a repackaged phpmyadmin) from the modules page.
- Upload it to your server in the moodle/admin folder.
- Go back to your moodle site and you should see a manage database icon and link on the bottom left of the main page. It looks like a stack of grey plates.
- Click that database link.
- Find the table for your users from the left hand frame, a long list of tables (this is not really necessary, you could execute the command from any of the tables) which is probably "moodle_users."
- In the main right hand frame click on the "SQL" tab
- Inside the box that then appears, delete what is in there, and add the following line
UPDATE moodle_user SET maildisplay = 0
(I tried "UPDATE user SET maildisplay = 0" but my tables have the prefix "moodle_" so I was told "there is not table 'user'." Perhaps that is a result of my Moodle confg.php settings. If your tables in the left hand navigation frame do not have that prefix, or have adifferent one, then you will have to change "moodle_users" accordingly. )- Press execute
All of your users mail settings should then to be set to be not displayed.
It would be nice if there were a button for doing this.
Indeed it would be nice if there were a security page in the admin page for changing everying on a site wide basis.
Since all my students are from the same town I decided to change the translation of town to mobile phone number. Subsequently all the students mobile phone numbers were on display to everyone. I managed to hack moodle so that these were only on display to teachers. But one of the students spotted the miss and was annoyed, as you would expect.
It would be nice to be able to control information on a site wide basis.
Timothy Takemoto
Thank you -- this is what I did. I had to prefix mine with "mdl_", but I figured it out.
In the above thread, it mentions doing this periodically and regularly, like a cron job. Is that necessary, or does one command do the trick?
Dear Jill Kaminski
Sorry I took weeks to reply. You only need to do the MYSQL command once, for all the students that are enrolled at the time of the command. If students enroll subsequently, then you may have to use the command again.
I am sure you have worked this out by now, but just for the record.
By the way, fiddling with the data base is dangerous.
Tim