https://docs.moodle.org/20/en/api.php?action=feedcontributions&user=Moorejon&feedformat=atomMoodleDocs - User contributions [en]2024-03-28T13:39:45ZUser contributionsMediaWiki 1.39.6https://docs.moodle.org/20/en/index.php?title=Enrolment_rewrite_and_role_tweaks_proposal&diff=53622Enrolment rewrite and role tweaks proposal2009-04-01T01:14:44Z<p>Moorejon: /* Why limit enrolment plugins to only assign at course level? */</p>
<hr />
<div>I don't understand this point, could you clarify what you mean: "parental access not supported in require_login() and other parts" --[[User:Dan Poltawski|Dan Poltawski]] 15:48, 22 March 2009 (UTC)<br />
<br />
<br />
== Why limit enrolment plugins to only assign at course level? ==<br />
This is the big question I have with this proposal. I think we should allow enrolment plugins to assign roles at any context. This will then allow for external systems to help save time in more scenarios. Two examples I am making up:<br />
<br />
* All geography teachers having rights to manage the geography category,<br />
* All students of class 11C & 11B being given moderator rights for a forum <br />
<br />
If the teacher can then assign these roles by choosing the global groups rather than individually selecting the students this will be a great advantage, save time etc. Limiting the enrolment plugins to only deal with courses limits a lot of future scenarios where having this facility at any context would be advantageous.<br />
<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:09, 22 March 2009 (UTC)<br />
<br />
Add my +1 to having "enrollment plugins" (maybe we should call them role assignment plugins) be able to operate in contexts besides just course. This comes up very often. For example with LDAP integrations users want to assign a global role like Administrator access based on membership in an LDAP group. Others want to automate the cumbersome process of matching user to user roles for parent/student supervisor/employee type relationships. It doesn't matter to me if these are a separate plugin type, but just that we get the functionality which doesn't seem to have quite caught up with the new role system. Another issues is the lack of support for custom profile fields in most of these automation plugins.<br />
<br />
--[[User:Jonathan Moore|jonathan]] 01:11, 1 April 2009 (UTC)<br />
<br />
<br />
Good question Dan. After 1.6 anything sticking out of courses was causing major problems in areas like backup, performance, etc. I hope that global groups have a potential to solve majority of issues. I would personally vote for keeping enrolment plugins course only and setting up new different types of plugins. We could also handle roles above course context in auth plugins and use enrolment plugins for course level and bellow. Course participation is a very important concept, I do think we should keep enrolment plugins strictly for this purpose.<br />
<br />
* All geography teachers having rights to manage the geography category - might be a synchronisation of global group with role assignments in given course category, maybe we could add a new field which links global group; another possibility is to add this into custom auth plugin<br />
* All students of class 11C & 11B being given moderator rights for a forum - this should be easy with proposed global groups, global groups enrolment plugins would handle course enrolment, role assignments and group membership<br />
--[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 17:28, 22 March 2009 (UTC)<br />
<br />
<br />
Hmm, so let me see if I understand what you are proposing:<br />
# A plugin system to populate global groups<br />
# A seperate plugin system to populate enrollments<br />
# Global groups used as a mechanism to populate groups of role assignments at non-course level<br />
<br />
If that is correct, my comments are:<br />
* How would role assignments related to enrolments in a course be assigned. In the majority of cases a course participant will also want to be assigned the student role. How will this be handled?<br />
* The enrollment/global group plugins will have *loads* of commonality - it would be good to avoid duplication here. (E.g. ldap plugin might populate a tree of courses, or a tree of groups, but essentially doing the smae here)<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:51, 24 March 2009 (UTC)<br />
<br />
== Comments from Tim ==<br />
<br />
Minor comments:<br />
<br />
* I know it is only a detail, but are the savings from using timeend = 2147483647 rather than timeend = 0 (or timeend = NULL) really worth it in course_participant DB table?<br />
** Quick test, SELECT * FROM test WHERE col < 2 does not select rows where col is NULL, so you have to do SELECT * FROM test WHERE col < 2 OR col IS NULL, but that should be quite fast.<br />
* Coding guidelines say it should be course_participants with an s on the end, and the same for other tables.<br />
* enrol_plugin_instance.name, is that really a name, or would calling the column shortname make it clearer what is going on.<br />
* Columns like roleid1, roleid2, customint1, customint2 are really sucky. Much better to do what modules and question types do, where there is a core table with the info that Moodle really needs, then plugins that need more define their own table that joins on.<br />
* If we need to keep the metacourse functionality as it is now, the solution is a metacourse enrolment plugin, that enrols someone on one course if they have a role in another.<br />
* 'New permission evaluation' I still think the is not sufficiently rich to meet all the required use cases.<br />
* I am not sure that moodle/course:inspect is the best name. moodle/course:visit is my alternative suggestion.<br />
* Hidden role assignments not needed - I agree.<br />
* Admin role restrictions - I think we should kill 'doanything' magic cap, and instead user role.archetype == 'admin'.<br />
* I agree with 'Editor' role (although again I am not sure it is the best name. Except, does it need to be different from Course creator?<br />
* I think global group table names should be global_groups and global_group_members.<br />
* 'Role assignment time restrictions moved to course participation table and plugins' - I agree. role_assignments should become a snapshot of the current roles situation only.<br />
* I don't see the need for multiple assignment of the same role in the same context, surely we only need one, even though two plugins are granting it. (are we going to lose role_assignments.enrol column? - ah, no, just change the unique index. That is probably OK.)<br />
* For functions returning complex queries like get_participating_courses_sql, I was wondering if we needed a set of classes for representing SQL queries. That might make it easier to manipulate them in memory, rather than relying on string manipulation.<br />
<br />
My big concerns:<br />
<br />
* A agree with Dan that enrolment plugins should be able to assign users to any role in any context, if they want to.<br />
** I would like to see a generalised replacement for the 'metacourse' enrolment plugin, that can do things like "Enrol every user who is a teacher in any course as 'Editor' in the system context." - up until now, we have never come up with a satisfactory replacement for is_teacher_any_course - and it would be nice to offer that, and more flexibility.<br />
<br />
* Not sure about my second concern, please could you post pseudo-code for what require_login() will look like under this proposal (without caching), so I can think some more.</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Enrolment_rewrite_and_role_tweaks_proposal&diff=53621Enrolment rewrite and role tweaks proposal2009-04-01T01:14:27Z<p>Moorejon: /* Why limit enrolment plugins to only assign at course level? */</p>
<hr />
<div>I don't understand this point, could you clarify what you mean: "parental access not supported in require_login() and other parts" --[[User:Dan Poltawski|Dan Poltawski]] 15:48, 22 March 2009 (UTC)<br />
<br />
<br />
== Why limit enrolment plugins to only assign at course level? ==<br />
This is the big question I have with this proposal. I think we should allow enrolment plugins to assign roles at any context. This will then allow for external systems to help save time in more scenarios. Two examples I am making up:<br />
<br />
* All geography teachers having rights to manage the geography category,<br />
* All students of class 11C & 11B being given moderator rights for a forum <br />
<br />
If the teacher can then assign these roles by choosing the global groups rather than individually selecting the students this will be a great advantage, save time etc. Limiting the enrolment plugins to only deal with courses limits a lot of future scenarios where having this facility at any context would be advantageous.<br />
<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:09, 22 March 2009 (UTC)<br />
<br />
Add my +1 to having "enrollment plugins" (maybe we should call them role assignment plugins) be able to operate in contexts besides just course. This comes up very often. For example with LDAP integrations users want to assign a global role like Administrator access based on membership in an LDAP group. Others want to automate the cumbersome process of matching user to user roles for parent/student supervisor/employee type relationships. It doesn't matter to me if these are a separate plugin type, but just that we get the functionality which doesn't seem to have quite caught up with the new role system. Another issues is the lack of support for custom profile fields in most of these automation plugins.<br />
--[[User:Jonathan Moore|jonathan]] 01:11, 1 April 2009 (UTC)<br />
<br />
<br />
Good question Dan. After 1.6 anything sticking out of courses was causing major problems in areas like backup, performance, etc. I hope that global groups have a potential to solve majority of issues. I would personally vote for keeping enrolment plugins course only and setting up new different types of plugins. We could also handle roles above course context in auth plugins and use enrolment plugins for course level and bellow. Course participation is a very important concept, I do think we should keep enrolment plugins strictly for this purpose.<br />
<br />
* All geography teachers having rights to manage the geography category - might be a synchronisation of global group with role assignments in given course category, maybe we could add a new field which links global group; another possibility is to add this into custom auth plugin<br />
* All students of class 11C & 11B being given moderator rights for a forum - this should be easy with proposed global groups, global groups enrolment plugins would handle course enrolment, role assignments and group membership<br />
--[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 17:28, 22 March 2009 (UTC)<br />
<br />
<br />
Hmm, so let me see if I understand what you are proposing:<br />
# A plugin system to populate global groups<br />
# A seperate plugin system to populate enrollments<br />
# Global groups used as a mechanism to populate groups of role assignments at non-course level<br />
<br />
If that is correct, my comments are:<br />
* How would role assignments related to enrolments in a course be assigned. In the majority of cases a course participant will also want to be assigned the student role. How will this be handled?<br />
* The enrollment/global group plugins will have *loads* of commonality - it would be good to avoid duplication here. (E.g. ldap plugin might populate a tree of courses, or a tree of groups, but essentially doing the smae here)<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:51, 24 March 2009 (UTC)<br />
<br />
== Comments from Tim ==<br />
<br />
Minor comments:<br />
<br />
* I know it is only a detail, but are the savings from using timeend = 2147483647 rather than timeend = 0 (or timeend = NULL) really worth it in course_participant DB table?<br />
** Quick test, SELECT * FROM test WHERE col < 2 does not select rows where col is NULL, so you have to do SELECT * FROM test WHERE col < 2 OR col IS NULL, but that should be quite fast.<br />
* Coding guidelines say it should be course_participants with an s on the end, and the same for other tables.<br />
* enrol_plugin_instance.name, is that really a name, or would calling the column shortname make it clearer what is going on.<br />
* Columns like roleid1, roleid2, customint1, customint2 are really sucky. Much better to do what modules and question types do, where there is a core table with the info that Moodle really needs, then plugins that need more define their own table that joins on.<br />
* If we need to keep the metacourse functionality as it is now, the solution is a metacourse enrolment plugin, that enrols someone on one course if they have a role in another.<br />
* 'New permission evaluation' I still think the is not sufficiently rich to meet all the required use cases.<br />
* I am not sure that moodle/course:inspect is the best name. moodle/course:visit is my alternative suggestion.<br />
* Hidden role assignments not needed - I agree.<br />
* Admin role restrictions - I think we should kill 'doanything' magic cap, and instead user role.archetype == 'admin'.<br />
* I agree with 'Editor' role (although again I am not sure it is the best name. Except, does it need to be different from Course creator?<br />
* I think global group table names should be global_groups and global_group_members.<br />
* 'Role assignment time restrictions moved to course participation table and plugins' - I agree. role_assignments should become a snapshot of the current roles situation only.<br />
* I don't see the need for multiple assignment of the same role in the same context, surely we only need one, even though two plugins are granting it. (are we going to lose role_assignments.enrol column? - ah, no, just change the unique index. That is probably OK.)<br />
* For functions returning complex queries like get_participating_courses_sql, I was wondering if we needed a set of classes for representing SQL queries. That might make it easier to manipulate them in memory, rather than relying on string manipulation.<br />
<br />
My big concerns:<br />
<br />
* A agree with Dan that enrolment plugins should be able to assign users to any role in any context, if they want to.<br />
** I would like to see a generalised replacement for the 'metacourse' enrolment plugin, that can do things like "Enrol every user who is a teacher in any course as 'Editor' in the system context." - up until now, we have never come up with a satisfactory replacement for is_teacher_any_course - and it would be nice to offer that, and more flexibility.<br />
<br />
* Not sure about my second concern, please could you post pseudo-code for what require_login() will look like under this proposal (without caching), so I can think some more.</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Enrolment_rewrite_and_role_tweaks_proposal&diff=53620Enrolment rewrite and role tweaks proposal2009-04-01T01:11:38Z<p>Moorejon: /* Why limit enrolment plugins to only assign at course level? */</p>
<hr />
<div>I don't understand this point, could you clarify what you mean: "parental access not supported in require_login() and other parts" --[[User:Dan Poltawski|Dan Poltawski]] 15:48, 22 March 2009 (UTC)<br />
<br />
<br />
== Why limit enrolment plugins to only assign at course level? ==<br />
This is the big question I have with this proposal. I think we should allow enrolment plugins to assign roles at any context. This will then allow for external systems to help save time in more scenarios. Two examples I am making up:<br />
<br />
* All geography teachers having rights to manage the geography category,<br />
* All students of class 11C & 11B being given moderator rights for a forum <br />
<br />
If the teacher can then assign these roles by choosing the global groups rather than individually selecting the students this will be a great advantage, save time etc. Limiting the enrolment plugins to only deal with courses limits a lot of future scenarios where having this facility at any context would be advantageous.<br />
<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:09, 22 March 2009 (UTC)<br />
<br />
Add my +1 to having "enrollment plugins" (maybe we should call them role assignment plugins) be able to operate in contexts besides just course. This comes up very often. For example with LDAP integrations users want to assign a global role like Administrator access based on membership in an LDAP group. Others want to automate the cumbersome process of matching user to user roles for parent/student supervisor/employee type relationships. <br />
--[[User:Jonathan Moore|jonathan]] 01:11, 1 April 2009 (UTC)<br />
<br />
<br />
Good question Dan. After 1.6 anything sticking out of courses was causing major problems in areas like backup, performance, etc. I hope that global groups have a potential to solve majority of issues. I would personally vote for keeping enrolment plugins course only and setting up new different types of plugins. We could also handle roles above course context in auth plugins and use enrolment plugins for course level and bellow. Course participation is a very important concept, I do think we should keep enrolment plugins strictly for this purpose.<br />
<br />
* All geography teachers having rights to manage the geography category - might be a synchronisation of global group with role assignments in given course category, maybe we could add a new field which links global group; another possibility is to add this into custom auth plugin<br />
* All students of class 11C & 11B being given moderator rights for a forum - this should be easy with proposed global groups, global groups enrolment plugins would handle course enrolment, role assignments and group membership<br />
--[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 17:28, 22 March 2009 (UTC)<br />
<br />
<br />
Hmm, so let me see if I understand what you are proposing:<br />
# A plugin system to populate global groups<br />
# A seperate plugin system to populate enrollments<br />
# Global groups used as a mechanism to populate groups of role assignments at non-course level<br />
<br />
If that is correct, my comments are:<br />
* How would role assignments related to enrolments in a course be assigned. In the majority of cases a course participant will also want to be assigned the student role. How will this be handled?<br />
* The enrollment/global group plugins will have *loads* of commonality - it would be good to avoid duplication here. (E.g. ldap plugin might populate a tree of courses, or a tree of groups, but essentially doing the smae here)<br />
--[[User:Dan Poltawski|Dan Poltawski]] 16:51, 24 March 2009 (UTC)<br />
<br />
== Comments from Tim ==<br />
<br />
Minor comments:<br />
<br />
* I know it is only a detail, but are the savings from using timeend = 2147483647 rather than timeend = 0 (or timeend = NULL) really worth it in course_participant DB table?<br />
** Quick test, SELECT * FROM test WHERE col < 2 does not select rows where col is NULL, so you have to do SELECT * FROM test WHERE col < 2 OR col IS NULL, but that should be quite fast.<br />
* Coding guidelines say it should be course_participants with an s on the end, and the same for other tables.<br />
* enrol_plugin_instance.name, is that really a name, or would calling the column shortname make it clearer what is going on.<br />
* Columns like roleid1, roleid2, customint1, customint2 are really sucky. Much better to do what modules and question types do, where there is a core table with the info that Moodle really needs, then plugins that need more define their own table that joins on.<br />
* If we need to keep the metacourse functionality as it is now, the solution is a metacourse enrolment plugin, that enrols someone on one course if they have a role in another.<br />
* 'New permission evaluation' I still think the is not sufficiently rich to meet all the required use cases.<br />
* I am not sure that moodle/course:inspect is the best name. moodle/course:visit is my alternative suggestion.<br />
* Hidden role assignments not needed - I agree.<br />
* Admin role restrictions - I think we should kill 'doanything' magic cap, and instead user role.archetype == 'admin'.<br />
* I agree with 'Editor' role (although again I am not sure it is the best name. Except, does it need to be different from Course creator?<br />
* I think global group table names should be global_groups and global_group_members.<br />
* 'Role assignment time restrictions moved to course participation table and plugins' - I agree. role_assignments should become a snapshot of the current roles situation only.<br />
* I don't see the need for multiple assignment of the same role in the same context, surely we only need one, even though two plugins are granting it. (are we going to lose role_assignments.enrol column? - ah, no, just change the unique index. That is probably OK.)<br />
* For functions returning complex queries like get_participating_courses_sql, I was wondering if we needed a set of classes for representing SQL queries. That might make it easier to manipulate them in memory, rather than relying on string manipulation.<br />
<br />
My big concerns:<br />
<br />
* A agree with Dan that enrolment plugins should be able to assign users to any role in any context, if they want to.<br />
** I would like to see a generalised replacement for the 'metacourse' enrolment plugin, that can do things like "Enrol every user who is a teacher in any course as 'Editor' in the system context." - up until now, we have never come up with a satisfactory replacement for is_teacher_any_course - and it would be nice to offer that, and more flexibility.<br />
<br />
* Not sure about my second concern, please could you post pseudo-code for what require_login() will look like under this proposal (without caching), so I can think some more.</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Development_talk:Course_completion&diff=37953Development talk:Course completion2008-06-21T02:30:39Z<p>Moorejon: view resources as completion requirement</p>
<hr />
<div>Many of the users that ask about this also bring up wanting to be able to set resources viewed as a criteria for course completion. Can this be added as one of the features for course completion?</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Projects_for_new_developers&diff=33749Projects for new developers2008-03-18T14:50:46Z<p>Moorejon: /* Roles interface improvements */</p>
<hr />
<div>This page lists possible student projects in Moodle, in particular suggestions for GSOC 2008 projects.<br />
__NOTOC__<br />
==To do this week (17th - 24th March 2008)==<br />
<br />
*Would-be GSOC student participants please discuss your application ideas in the [http://moodle.org/mod/forum/view.php?id=7105 Moodle.org Student projects forum]. ''You're welcome to suggest ideas for projects too!''<br />
*Moodlers willing to mentor a GSOC project, please add your name to a project on this page.<br />
<br />
<br />
__TOC__<br />
== Secure RSS feeds ==<br />
<br />
Currently RSS is less than useful because:<br />
* Either we can't publish private information to the outside world because it's too sensitive.<br />
* We open up sensitive information to the outside world<br />
<br />
We should add codes to make the RSS URLs practically impossible to guess, much the same way as Google Calendar does it.<br />
<br />
* Overhaul all the RSS feeds in Moodle to make use of a long hash-like string in the URL for identification (Forums, Data etc).<br />
* Store these codes in a new field per-user and per-course. <br />
* Add GUIs to let the user recreate their code to something else should they suspect a breach.<br />
* Add RSS to other areas of Moodle such as the participants "last logins" and the activity logs.<br />
* Explore/research other methods of opening up RSS in a safe way to the outside world.<br />
<br />
'''Old Specification:''' [[Student projects/Secure RSS feeds|Secure RSS feeds]]<br />
<br />
== Roles interface improvements ==<br />
<br />
Improve the roles editing interface by making it more dynamic and flexible. You can use the YUI library for ajax if you like, but there must be a good fall-back interface too. Some ideas include:<br />
<br />
* Improve the order of the capabilities and implement better grouping.<br />
* Make the groups of capabilities collapsible to make it easier to "zoom in" to a particular section.<br />
* Add floating tooltip help when you hover over any given capability.<br />
* Experiment with an (alternate) interface seeing the roles all side-by-side for easier comparison/editing.<br />
* Implement a roles backup and restore system to allow site administrators to distribute useful roles in the Moodle community (rather than having to describe the permissions setup)<br />
* More clearly designate the scope of capabilities. Does the capability apply at the site, category, course, activity, or user to user levels.<br />
* Analyse the problem carefully with feedback from the community for more ideas.<br />
<br />
==Integration with bibliographic systems such as Wikindx==<br />
<br />
Managing references and citing them is an important behaviour in university education and research. Bibliographic facilities are quite complicated and go beyond the capabilities of Moodle built-in technology (e.g. the database activity). Integrating Moodle with open-source bibliographic software such as [http://wikindx.sourceforge.net/ Wikindx] could much facilitate this practice within Moodle.<br />
<br />
Design and construct an integration with Wikindx (or other open-source bibliographic tools, if appropriate).<br />
<br />
Teachers should be able to easily refer to wikindx bibliography items throughout a Moodle course, and be able to:<br />
<br />
* Generate correctly-formatted in-place references (using standard styles e.g. Harvard, APA) for the commonly-cited reference types (e.g. journal article, book chapter, book). It may be possible to delegate the formatting directly to wikindx (since it already performs functions like these) rather than implementing a whole new set of logic in the Moodle integration.<br />
** Possibly, allow some kind of direct searching of a wikindx database from within Moodle, so as to make it easier to refer to items<br />
* Generate reading lists / bibliographies<br />
* Allow export of the above into common machine-readable formats such as Bibtex or RIS. (Wikindx can perform this so again it's a question of hooking into, or expanding, wikindx functionality.)<br />
<br />
See also [[Development:Wikindx]] and [http://moodle.org/mod/forum/discuss.php?d=23022 this forum discussion] too<br />
<br />
==Implement CATs in Moodle==<br />
<br />
[http://www.amazon.com/Classroom-Assessment-Techniques-Handbook-Education/dp/1555425003/ This book] describes a number of assessment techniques that involve collaboration and group work, and therefore fit very well into Moodle's Social Constructivist philosophy. The book about using these techniques in the classroom, but at an conference I attended there was a talk by Jean Runyon and Thomas Gorecki from the College of Southern Maryland saying how well these techniques work online. <br />
<br />
Some of them just need a forum of something basic, but others would need to be done as a database module templates. Doing this would<br />
<br />
# Make Moodle an even better teaching tool.<br />
# Provide some good exemplars of how to do interesting things with database templates.<br />
# Possibly highlight limitations in the database template system, that would require improvements to the database module code to overcome.<br />
# One of the outcomes of this project could be some really good 'How to write a database template' tutorial, which would be very valuable to the community.<br />
<br />
This is my (Tim Hunt's) idea, but I would not be interested in mentoring it. It would need to be someone who knows all about the database module.<br />
<br />
== Blog Assignment Type ==<br />
<br />
'''What is it for?'''<br />
<br />
Blogs are inherently user owned and driven by definition, however teachers would like to have a way to use blogs as assignments in their courses, comment, grade, etc.<br />
<br />
A solution to this conundrum would be a new Assignment type that makes it possible for a student to easily submit the link one of their blogs to an assignment in a course, and have that blog entry privately graded and commented on by the instructor of that course. The blog entry itself remains public along with all of the student's other blogs. The tool would provide a time filter in the Assignment, so that the instructor could limit the blog entry posting dates that will be accepted (both to ensure 'fresh' entries and to keep the list of entries the student chooses short for frequent student bloggers).<br />
<br />
I suggest a blog assignment type that functions as follows:<br />
<br />
'''Teacher:'''<br />
Teacher creates a blog assignment, this puts a grade in the gradebook and provides an assignment link for students to see.<br />
<br />
The teacher can configure options to allow a blog entry posted in the last X days to be used for the assignment.<br />
<br />
'''Students:'''<br />
When students enter the assignment they see a drop down menu of all their current (blog entries posted in the last X days as chosen by the teacher) blog entries, and they choose one to satisfy the assignment.<br />
<br />
'''Assessment:'''<br />
The teacher goes in to the Assignment, views the blogs that are linked from the assignment, leaves comments (the comments only show up to the student when they view the blog assignment), and gives a grade.<br />
<br />
The blog entries themselves stay on the student's blog, only the grades, links, and comments go in the assignment (optionally the assignment scrapes the student's blog and loads the full text in to store for backup and restore).<br />
<br />
== Moodle IDE ==<br />
The objective of this project is to create a Moodle IDE based on Eclipse so that new developers can get to develop Moodle in less time.<br />
<br />
'''Ideas'''<br />
* First release: Eclipse + Plugins + Moodle splashscreen + CVS Configuration + Apache + MySQL + Moodle CVS code. All preconfigured and ready out of the box.<br />
* Every X time, it checks for new versions of Moodle and packs it.<br />
* Checkstyle plugin alike fo follow Moodle Design Guidelines.<br />
* Development help (can be wiki pages to navigate offline)<br />
<br />
'''More mentors needed'''<br />
'''Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]<br />
<br />
'''Download (Old Version)''': [http://mirrors.davidhorat.com/moodle/MoodleIDE-latest.zip MoodleIDE-latest]<br />
<br />
'''Join the [http://moodle.org/mod/forum/discuss.php?d=92859 discussion thread]'''<br />
<br />
== Moodle Multisite ==<br />
The objective of this project is to make Moodle able to manage several Moodle sites with just one source code. This will help administrators of several sites to centralize code upgrades and ''technical problems''.<br />
<br />
'''Ideas'''<br />
* config.php will be a proxy that executes the concrete config file depending on the current url.<br />
* The concrete config file will be under the directory /config and will have an arbitrary name created by the user.<br />
* Create an XML file with all the pairs URL(n)-ConfigFile(1).<br />
* Every time this file changes, it should be created the config.php file cache (to speed up things).<br />
* Develop a Web frontend to change this file, that can be just accessed by the super admin in every site.<br />
<br />
'''Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]<br />
<br />
'''Join the [http://moodle.org/mod/forum/discuss.php?d=92860 discussion thread]'''<br />
<br />
== Automatic Accesibility Checking ==<br />
The objective of this project is to make a tool that can check Moodle´s accesibility automatically before realising a version.<br />
<br />
'''Ideas'''<br />
* Automatic Tool (see down)<br />
* Create an example course which introduces every XHTML code of the Moodle application, in order to have a way to test it.<br />
* Create a button called "Check XHTML" which will send the current page code to a validator.<br />
** This button just helps to check if the current page is valid. Good for development purposes.<br />
** This button will be (de)activated in the administration panel<br />
** Keep in mind that this button will not pass the URL as a referer, but it will take all the code from the page and send it to the validation service<br />
** This button can be used in other web applications<br />
<br />
'''Automatic Tool'''<br />
* Create (or use an existing one) an automatic and easy to use tool that retrieves all the pages in a site until a concrete level (recursive calling it for each link)<br />
** Use concrete user agent names<br />
** Be able to store cookies in order to check it with a concrete user and password<br />
* Plug each output to an automatic XHTML validator<br />
** In the future we can plug in different validators: CSS, WCAG (what it can be checkable automaticly), etc.<br />
* Generate stats<br />
<br />
'''Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]<br />
<br />
'''Join the [http://moodle.org/mod/forum/discuss.php?d=92861 discussion thread]'''<br />
<br />
== Moodle Usability Guidelines ==<br />
The main objective of this project is to develop a usability guidelines and testing methods in order to have a real view of Moodle usage.<br />
<br />
'''Main tasks'''<br />
* Research in the usability world to see which methods are most used and which are most reliable.<br />
* Select the ones that are more appropiate for Moodle<br />
* Create a usability guideline with the way to apply these methods for Moodle<br />
* Try them with real world people (optional, although it would be very interesting)<br />
* Analyse the results in order to extract conclusions of the current Moodle Usage<br />
* Report the ways we could improve current Moodle Usability<br />
<br />
'''Mentor''': [http://moodle.org/user/view.php?id=153093&course=1 David Horat]<br />
<br />
'''Join the [http://moodle.org/mod/forum/discuss.php?d=92862 discussion thread]'''<br />
<br />
==Moodle Target tracking + rewards/gifts==<br />
This one would suit a facebook enthusiast! The Facebook gifts system is very popular and an ideal motivator for students at school level. Moodle needs an equivalent.<br />
<br />
The aim is to develop a system for setting targets e.g. 'get at least 60% in this assignment/quiz/whatever' and for reward credits to be awarded automatically when it is completed. These reward credits translate to a system of Gifts similar to facebook ones (small images, akin to stickers, which can be bought for a small fee and sent to friends who then display them on their profile). Admins can control what the reward images are for their site, maybe having them in some sort of rank order of value, or having different ones with different meanings. There are several ways they could be implemented beyond that:<br />
* Teachers could choose which rewards can be earned for a specific task. For example, there may be different rewards for forums and assignments<br />
* Teachers may want to specify different rewards for different levels of performance on the same task<br />
* Teachers decide how many points a certain target is worth and the students cash in those points for rewards of various values<br />
* Teachers decide how many rewards a target is worth and students choose that many rewards. None are worth more than 1 point each, the only difference is the graphic.<br />
Once students have rewards, they need a way of allocating them (presumably permanently) to their friends. A system for logically displaying them on the friend's profile page would be needed too and will need to take into account<br />
* Students with only a few stickers given to them by friends will want them to maximise their display<br />
* Students who are very popular with hundreds of stickers may need to groups of 10 similar ones substituted for a super-sticker to use less space<br />
* Hovering over the sticker should give details of who awarded it and when and possibly a short message.<br />
Additionally, the social rating/ranking that this achieves will have most effect when it is publicly visible in various places e.g. under forum avatars and maybe in the online users block as well as the user profile. <br />
<br />
Maybe this would sit well with the 'Friends' part of last years GSOC social networking project if it were finished.<br />
<br />
I can't offer to mentor in coding terms, but will help with ideas all I can. [[User:Matt Gibson|Matt Gibson]] 05:26, 4 March 2008 (CST)<br />
<br />
==Use of Video Material Effectively within Moodle==<br />
The main purpose of this module will be to get use of video content, most probably a lecture, in a more fomal/controled/affective way within moodle.<br />
<br />
The main features of this module will be;<br />
* Stream the video file (most probably in flv format)<br />
** Should be able to stream by using multiple ways (e.x. FMS, Red5, lighttpd, etc..)<br />
** Develop a fronted to configure the streaming server settings<br />
** automatic media conversion (controlled by other moodle settings like max file size, etc..)<br />
* The teacher can give related notes, websites or other resources with the video<br />
* The students can keep a note related to each video<br />
* Share/view other student's notes (probably controlled by the teachers and/or students)<br />
* Optionally asses the student notes and include them in the grade book <br />
<br />
The above list may expanded based on your views.<br />
<br />
'''Difficulty Level:''' Easy/Medium<br />
<br />
'''Skills Required:'''<br />
* Familiarity with Streaming Servers like Red5 and video streaming in general.<br />
* Should be able to install and configure required products (Moodle, Red5, lighttpd, etc..) in any OS (Windows, Linux, Mac, etc..)<br />
* Understanding of UI design concepts.<br />
* Familiarity with Moodle APIs and [[Developer_documentation |Developing Moodle in general]]<br />
<br />
'''Join the [http://moodle.org/mod/forum/discuss.php?d=92310 discussion thread]'''<br />
<br />
'''References'''<br />
* [http://moodle.org/mod/data/view.php?rid=931&page=102 FlashVideo]<br />
* [http://osflash.org/red5 RED5 Open Source Streaming Server]<br />
<br />
<br />
'''Potential Mentor:''' [http://moodle.org/user/edit.php?id=68520 Rashan Anushka]<br />
<br />
----<br />
<br />
==Web-based upgrade and plugins interface==<br />
A system for Moodle to be upgraded along with its plugins from within the admin interface.<br />
<br />
Currently, adding third party modules/patches can be messy and can especially slow down the upgrade process if CVS is not used. The aim would be to develop a way to package plugins in a standardised way so that a single zip file could be retrieved and installed automatically, similar to the way courses are restored. An added feature would be for the modules and plugins database on moodle.org to have an XML index so that you could browse available plugins from within your own moodle instance and have a one-click install option. Version compatibility info could be included so that only those which will work with your install will be shown. At upgrade time, the new third-party components screen could then show which ones could be upgraded along with the rest of the code and which would need to dropped because there is no compatible replacement.<br />
<br />
==See also==<br />
<br />
* [[GSOC]], including a list of GSOC projects from 2006 and 2007<br />
* [http://moodle.org/mod/forum/discuss.php?d=92797 this forum thread] about work that might be done this summer, although as part of something other than GSOC.<br />
<br />
[[Category:Developer]]<br />
[[Category:Project]]</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Upgrading&diff=9127Upgrading2006-05-03T18:06:41Z<p>Moorejon: </p>
<hr />
<div>Moodle is designed to upgrade cleanly from any earlier version to any later version.<br />
<br />
When upgrading a Moodle installation you should follow these steps:<br />
<br />
== Backup important data ==<br />
<br />
Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.<br />
<br />
There are three areas that need backing up:<br />
<br />
=== The Moodle software directory itself ===<br />
<br />
Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc<br />
<br />
=== Your data directory ===<br />
<br />
This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.<br />
<br />
=== Your database ===<br />
<br />
Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":<br />
<br />
mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2002-10-26.sql<br />
<br />
Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.<br />
<br />
You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. This interface can be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.<br />
<br />
== Install the new Moodle software ==<br />
<br />
=== Using a downloaded archive ===<br />
<br />
Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.<br />
<br />
mv moodle moodle.backup<br />
tar xvzf moodle-1.1.tgz<br />
<br />
Next, copy across your config.php and any other plugins such as custom themes:<br />
<br />
cp moodle.backup/config.php moodle<br />
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme<br />
<br />
=== Using CVS ===<br />
<br />
You can use CVS for updating or upgrading your Moodle.<br />
First you need to do a CVS checkout in your (empty) Moodle root directory.<br />
<br />
''For Linux servers''<br />
<br />
To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.<br />
<br />
<nowiki>cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/moodle login</nowiki><br />
No password for anonymous, so just hit the Enter button.<br />
<br />
Go to the directory where you want the Moodle root to come and type<br />
<br />
<nowiki>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_15_STABLE moodle</nowiki> <br />
(where MOODLE_15_STABLE is the desired version)<br />
<br />
<br />
To update, just go into the Moodle root directory and update to the new files:<br />
<br />
cvs update -dP<br />
<br />
Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.<br />
<br />
''For Windows servers''<br />
<br />
You can use Tortoise CVS to do the initial checkout and the updates.<br />
<br />
<br />
If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.<br />
<br />
Don't forget to visit the admin page after the CVS update proces has completed.<br />
<br />
== Finishing the upgrade ==<br />
<br />
The last step is to trigger the upgrade processes within Moodle.<br />
<br />
To do this just visit the admin page of your installation - '''<nowiki>http://example.com/moodle/admin</nowiki>'''<br />
<br />
It doesn't matter if you are logged in as admin or not.<br />
<br />
Moodle will automatically detect the new version and perform all the database or filesystem upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.<br />
<br />
Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!<br />
<br />
If you have trouble with the upgrade, visit [http://moodle.org/ moodle.org] and post on the [http://moodle.org/mod/forum/view.php?id=28 Installation Support Forum] in the Using Moodle course.<br />
<br />
==See also==<br />
<br />
<br />
*[[Upgrading to Moodle 1.6]]<br />
*[[Installing Moodle]]<br />
*[[Installation FAQ]]<br />
*[[Installing Apache, MySQL and PHP]]<br />
*[[Step by Step Installation Guide for Windows]]<br />
*[[Step by Step Installation Guide for RedHat]]<br />
*[[Step by Step Installation Guide for Debian GNU/Linux]]<br />
*[http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs] forum discussion<br />
<br />
[[Category:Core]]<br />
[[Category:Administrator]]<br />
[[Category:Installation]]<br />
<br />
<br />
[[es:Actualización de moodle]]<br />
[[nl:Upgraden]]</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Upgrading&diff=9102Upgrading2006-05-03T04:42:08Z<p>Moorejon: </p>
<hr />
<div>Moodle is designed to upgrade cleanly from any earlier version to any later version.<br />
<br />
When upgrading a Moodle installation you should follow these steps:<br />
<br />
== Backup important data ==<br />
<br />
Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.<br />
<br />
There are three areas that need backing up:<br />
<br />
=== The Moodle software directory itself ===<br />
<br />
Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc<br />
<br />
=== Your data directory ===<br />
<br />
This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.<br />
<br />
=== Your database ===<br />
<br />
Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":<br />
<br />
mysqldump moodle -u username -p -C -Q -e -a mysqldump > moodle-backup-2002-10-26.sql<br />
<br />
Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.<br />
<br />
You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. This interface can be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.<br />
<br />
== Install the new Moodle software ==<br />
<br />
=== Using a downloaded archive ===<br />
<br />
Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.<br />
<br />
mv moodle moodle.backup<br />
tar xvzf moodle-1.1.tgz<br />
<br />
Next, copy across your config.php and any other plugins such as custom themes:<br />
<br />
cp moodle.backup/config.php moodle<br />
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme<br />
<br />
=== Using CVS ===<br />
<br />
You can use CVS for updating or upgrading your Moodle.<br />
First you need to do a CVS checkout in your (empty) Moodle root directory.<br />
<br />
''For Linux servers''<br />
<br />
To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.<br />
<br />
<nowiki>cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/moodle login</nowiki><br />
No password for anonymous, so just hit the Enter button.<br />
<br />
Go to the directory where you want the Moodle root to come and type<br />
<br />
<nowiki>cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_15_STABLE moodle</nowiki> <br />
(where MOODLE_15_STABLE is the desired version)<br />
<br />
<br />
To update, just go into the Moodle root directory and update to the new files:<br />
<br />
cvs update -dP<br />
<br />
Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.<br />
<br />
''For Windows servers''<br />
<br />
You can use Tortoise CVS to do the initial checkout and the updates.<br />
<br />
<br />
If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.<br />
<br />
Don't forget to visit the admin page after the CVS update proces has completed.<br />
<br />
== Finishing the upgrade ==<br />
<br />
The last step is to trigger the upgrade processes within Moodle.<br />
<br />
To do this just visit the admin page of your installation - '''<nowiki>http://example.com/moodle/admin</nowiki>'''<br />
<br />
It doesn't matter if you are logged in as admin or not.<br />
<br />
Moodle will automatically detect the new version and perform all the database or filesystem upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.<br />
<br />
Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!<br />
<br />
If you have trouble with the upgrade, visit [http://moodle.org/ moodle.org] and post on the [http://moodle.org/mod/forum/view.php?id=28 Installation Support Forum] in the Using Moodle course.<br />
<br />
==See also==<br />
<br />
<br />
*[[Upgrading to Moodle 1.6]]<br />
*[[Installing Moodle]]<br />
*[[Installation FAQ]]<br />
*[[Installing Apache, MySQL and PHP]]<br />
*[[Step by Step Installation Guide for Windows]]<br />
*[[Step by Step Installation Guide for RedHat]]<br />
*[[Step by Step Installation Guide for Debian GNU/Linux]]<br />
*[http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs] forum discussion<br />
<br />
[[Category:Core]]<br />
[[Category:Administrator]]<br />
[[Category:Installation]]<br />
<br />
<br />
[[es:Actualización de moodle]]<br />
[[nl:Upgraden]]</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5363Talk:Security recommendations2006-02-14T16:51:59Z<p>Moorejon: </p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly an existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. [[User:Moorejon|Moorejon]] Jonathan Moore 8:46, 12 February 2006 (CST)<br />
<br />
:Please, take a look at the "Before all" topic I have just added, based on Petr's opinion on this: http://moodle.org/mod/forum/discuss.php?d=39404#182024 - [[User:Davidds|David Delgado]] 02:11, 13 February 2006 (WST)<br />
<br />
<p class="note">Maybe we should take a look at the security in this "Security" page. :-/ Should it be a protected page maintained directly by http://security.moodle.org? Please, give us your opinion on this in the "page comments" label in this page.</p><br />
<br />
:I do think it SHOULD be protected and maintained directly by http://security.moodle.org , since it is the best place to introduce security hazards. Just add "Do not forget to send your admin password to safe@cracker.com", for example. Think also of more sophisticated cracking methods. By the way... moodledata directory owned by root with 700 permissions, [[User:Moorejon|Moorejon]]? :-/ - [[User:Davidds|David Delgado]] 16:44, 13 February 2006 (WST)<br />
<br />
== Security for Security page ==<br />
<br />
I think you make a good point. At a minimum this page needs to be monitored by someone. I think more subtle problems than the send password to x variety could be introduced too. Such as changing the permission numbers or some such.<br />
<br />
Since I am not a member of security.moodle.org, I can't speak for them. I don't know what all of their duties entail and whether there is a complete match up with what they cover for Moodle and what is covered in the guide.<br />
<br />
I have updated the file permissions, with what I hope are more correct values. [[User:Moorejon|Moorejon]] Jonathan Moore 10:52, 14 February 2006 (CST)</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5362Talk:Security recommendations2006-02-14T16:47:01Z<p>Moorejon: Security for Security page</p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly an existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. [[User:Moorejon|Moorejon]] Jonathan Moore 8:46, 12 February 2006 (CST)<br />
<br />
:Please, take a look at the "Before all" topic I have just added, based on Petr's opinion on this: http://moodle.org/mod/forum/discuss.php?d=39404#182024 - [[User:Davidds|David Delgado]] 02:11, 13 February 2006 (WST)<br />
<br />
<p class="note">Maybe we should take a look at the security in this "Security" page. :-/ Should it be a protected page maintained directly by http://security.moodle.org? Please, give us your opinion on this in the "page comments" label in this page.</p><br />
<br />
:I do think it SHOULD be protected and maintained directly by http://security.moodle.org , since it is the best place to introduce security hazards. Just add "Do not forget to send your admin password to safe@cracker.com", for example. Think also of more sophisticated cracking methods. By the way... moodledata directory owned by root with 700 permissions, [[User:Moorejon|Moorejon]]? :-/ - [[User:Davidds|David Delgado]] 16:44, 13 February 2006 (WST)<br />
<br />
== Security for Security page ==<br />
<br />
I think you make a good point. At a minimum this page needs to be monitored by someone. I think more subtle problems than the send password to x variety could be introduced too. Such as changing the permission numbers or some such.<br />
<br />
Since I am not a member of security.moodle.org, I can't speak for them. I don't know what all of their duties entail and whether there is a complete match up with what they cover for Moodle and what is covered in the guide.<br />
<br />
I have updated the file permissions, with what I hope are more correct values.</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Security_recommendations&diff=5360Security recommendations2006-02-14T16:32:45Z<p>Moorejon: /* Most secure/paranoid file permissions */</p>
<hr />
<div><p class="note">Maybe we should take a look at the security in this "Security" page. :-/ Should it be a protected page maintained directly by http://security.moodle.org? Please, give us your opinion on this in the "page comments" label in this page.</p><br />
<br />
All web application software is highly complex, and every application has security issues that are found from time to time, usually involving some conbination of input that the programmers did not anticipate. The Moodle project takes security seriously, and is continuously improving Moodle to close such holes as we find them.<br />
<br />
==Before all==<br />
*In this document, you will find important security measures for your Moodle installation.<br />
*You should report security problems directly at http://security.moodle.org - because developers might overlook it elsewhere, and they must not be released to general public until they are solved (to prevent attacks).<br />
*You should not post actual exploits in the bugtracker or forums, for exactly the same reasons.<br />
<br />
==Simple security measures==<br />
*The best security strategy is a good backup! But you don't have a good backup unless you are able to restore it. Test your restoration procedures!<br />
*Load only software or services you will use<br />
*Perform regular updates<br />
*Model your security after the layers of clothing you wear on a cold winter day<br />
<br />
==Basic recommendations==<br />
*Update Moodle regularly on each release<br />
**Published security holes draw crackers attention after release. The older the version, the more vulnerabilities it is likely to contain.<br />
*Disable register globals<br />
**This will help prevent against possible XSS problems in third-party scripts.<br />
*Use strong passwords for admin and teachers<br />
**Choosing "difficult" passwords is a basic security practice to protect against "brute force" cracking of accounts.<br />
*Only give teacher accounts to trusted users. Avoid creating public sandboxes with free teacher accounts on production servers.<br />
**Teacher accounts have much freer permissions and it is easier to create situations where data can be abused or stolen.<br />
*Separate your systems as much as possible<br />
**Another basic security technique is to use different passwords on different systems, use different machines for different services and so on. This will prevent damage being widespread even if one account or one server is compromised.<br />
<br />
==Run regular updates==<br />
*Use auto update systems<br />
*Windows Update <br />
*Linux: up2date, yum, apt-get<br />
**Consider automating updates with a script scheduled via cron <br />
*Mac OSX update system<br />
*Stay current with php, apache, and moodle<br />
<br />
==Use mailing lists to stay updated==<br />
*CERT <br />
**http://www.us-cert.gov/cas/signup.html<br />
*PHP<br />
**http://www.php.net/mailing-lists.php<br />
**Sign up for Announcements list<br />
*MySQL<br />
**http://lists.mysql.com<br />
**Sign up for MySQL Announcements<br />
<br />
==Firewalls==<br />
*Security experts recommend a dual firewall<br />
**Differing hardware/software combinations <br />
*Disabling unused services is often as effective as a firewall<br />
**Use netstat -a to review open network ports<br />
*Not a guarantee of protection<br />
*Allow ports <br />
**80, 443(ssl), and 9111 (for chat), <br />
**Remote admin: ssh 22, or rpd 3389<br />
<br />
==Be prepared for the worst==<br />
*Have backups ready <br />
*Practice recovery procedures ahead of time <br />
*Use a rootkit detector on a regular basis <br />
**Linux/MacOSX: <br />
***http://www.chkrootkit.org/ <br />
**Windows: <br />
***http://www.sysinternals.com/Utilities/RootkitRevealer.html<br />
<br />
==Moodle security alerts==<br />
*Register your site with Moodle.org<br />
**Registered users receive email alerts<br />
*Security alerts also posted online<br />
*Web<br />
**http://security.moodle.org/ <br />
*RSS feed<br />
**http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml<br />
<br />
==Miscellaneous considerations==<br />
*These are all things you might consider that impact your overall security<br />
*Turn off opentogoogle, esp for K12 sites<br />
*Use SSL, httpslogins=yes<br />
*Disable guest access<br />
*Place enrollment keys on all courses<br />
*Use good passwords<br />
*Use the secure forms setting<br />
*Set the mysql root user password<br />
*Turn off mysql network access<br />
<br />
==Most secure/paranoid file permissions==<br />
Assuming you are running this on a sealed server (i.e. no user logins allowed on the machine) and that root takes care of the modifications to both moodle code and moodle config (config.php), then this are the most tight permissions I can think of:<br />
<br />
1.- moodledata directory and all of its contents (and subdirs, includes sessions):<br />
owner: apache user (apache, httpd, www-data, whatever).<br />
group: apache group (apache, httpd, www-data, whatever)<br />
perms: 700 on directories, 600 on files.<br />
<br />
2.- moodle directory and all of its contents and subdirs (including config.php):<br />
owner: root<br />
group: root<br />
perms: 755 on directories, 644 on files.<br />
<br />
If you allow local logins, then 2.- should be:<br />
owner: root<br />
group: apache group<br />
perms: 750 on directories, 640 on files<br />
<br />
Think of these permissions as the most paranoid ones. You can be secure enough with less tighter permissions, both in moodledata and moodle directories (and subdirectories).<br />
<br />
==See also==<br />
*[http://moodle.org/mod/forum/discuss.php?d=39404 "Guide to Securing your Moodle Server" discussion] at [http://moodle.org http://moodle.org]<br />
<br />
[[Category:Administrator]]</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Security_recommendations&diff=5225Security recommendations2006-02-12T15:29:11Z<p>Moorejon: </p>
<hr />
<div>==Simple security measures==<br />
*The best security strategy is a good backup! <br />
*Load only software or services you will use<br />
*Perform regular updates<br />
*Model your security after the layers of clothing you wear on a cold winter day<br />
<br />
==Run regular updates==<br />
*Use auto update systems<br />
*Windows Update <br />
*Linux: up2date, yum, apt-get<br />
**Consider automating updates with a script scheduled via cron <br />
*Mac OSX update system<br />
*Stay current with php, apache, and moodle<br />
<br />
==Use mailing lists to stay updated==<br />
*CERT <br />
**http://www.us-cert.gov/cas/signup.html<br />
*PHP<br />
**http://www.php.net/mailing-lists.php<br />
**Sign up for Announcements list<br />
*MySQL<br />
**http://lists.mysql.com<br />
**Sign up for MySQL Announcements<br />
<br />
==Firewalls==<br />
*Security experts recommend a dual firewall<br />
**Differing hardware/software combinations <br />
*Disabling unused services is often as effective as a firewall<br />
**Use netstat -a to review open network ports<br />
*Not a guarantee of protection<br />
*Allow ports <br />
**80, 443(ssl), and 9111 (for chat), <br />
**Remote admin: ssh 22, or rpd 3389<br />
<br />
==Be prepared for the worst==<br />
*Have backups ready <br />
*Practice recovery procedures ahead of time <br />
*Use a rootkit detector on a regular basis <br />
**Linux/MacOSX: <br />
***http://www.chkrootkit.org/ <br />
**Windows: <br />
***http://www.sysinternals.com/Utilities/RootkitRevealer.html<br />
<br />
==Moodle security alerts==<br />
*Register your site with Moodle.org<br />
**Registered users receive email alerts<br />
*Security alerts also posted online<br />
*Web<br />
**http://security.moodle.org/ <br />
*RSS feed<br />
**http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml<br />
<br />
==Miscellaneous considerations==<br />
*These are all things you might consider that impact your overall security<br />
*Turn off opentogoogle, esp for K12 sites<br />
*Use SSL, httpslogins=yes<br />
*Disable guest access<br />
*Place enrollment keys on all courses<br />
*Use good passwords<br />
*Use the secure forms setting<br />
*Set the mysql root user password<br />
*Turn off mysql network access<br />
<br />
==Most secure/paranoid file permissions==<br />
*The moodle directory<br />
**Owner root <br />
**Group root<br />
**Permissions 755 directories, 644 files<br />
*The moodledata directory<br />
**Should be placed outside the webroot, or restricted via .htaccess file<br />
**Owner root<br />
**Group apache group<br />
**Permissions 700 directories, 600 files<br />
<br />
[[Category:Administrator]]</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5222Talk:Security recommendations2006-02-12T14:47:33Z<p>Moorejon: </p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly an existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. [[User:Moorejon|Moorejon]] Jonathan Moore 8:46, 12 February 2006 (CST)</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5221Talk:Security recommendations2006-02-12T14:47:00Z<p>Moorejon: </p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly an existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. [[User:Moorejon]] Jonathan Moore 8:46, 12 February 2006 (CST)</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5220Talk:Security recommendations2006-02-12T14:46:36Z<p>Moorejon: </p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly and existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned. [[User:Moorejon]] Jonathan Moore 8:46, 12 February 2006 (CST)</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Talk:Security_recommendations&diff=5219Talk:Security recommendations2006-02-12T14:45:29Z<p>Moorejon: </p>
<hr />
<div>Should this page deal with valid users as well? I'm talking about input sanitization, etc. For example, in my school's version of Moodle, I can craft some code that logs the user out as soon as they see my forum post. I suggest taking a look at MediaWiki's approach to code sanitizing. -- [[User:Phyzome|Phyzome]] is [[User talk:Phyzome|Tim McCormack]] 12:45, 11 February 2006 (WST)<br />
<br />
Tim, I believe what you are mentioning is actually related to the future development of Moodle code, or possibly and existing security bug? There is actually a lead Security Officer, Petr Škoda (skodak), who is charged with reviewing the security code. He would probably like to see an example of what you mentioned.</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Security_recommendations&diff=5131Security recommendations2006-02-10T21:50:54Z<p>Moorejon: </p>
<hr />
<div>=Simple Security Measures=<br />
*The best security strategy is a good backup! <br />
*Load only software or services you will use<br />
*Perform regular updates<br />
*Model your security after the layers of clothing you wear on a cold winter day<br />
<br />
=Run Regular Updates=<br />
*Use auto update systems<br />
*Windows Update <br />
*Linux: up2date, yum, apt-get<br />
**Consider automating updates with a script scheduled via cron <br />
*Mac OSX update system<br />
*Stay current with php, apache, and moodle<br />
<br />
= Use Mailing Lists to Stay Updated =<br />
*CERT <br />
**http://www.us-cert.gov/cas/signup.html<br />
*PHP<br />
**http://www.php.net/mailing-lists.php<br />
**Sign up for Announcements list<br />
*MySQL<br />
**http://lists.mysql.com<br />
**Sign up for MySQL Announcements<br />
<br />
=Firewalls=<br />
*Security experts recommend a dual firewall<br />
**Differing hardware/software combinations <br />
*Disabling unused services is often as effective as a firewall<br />
**Use netstat -a to review open network ports<br />
*Not a guarantee of protection<br />
*Allow ports <br />
**80, 443(ssl), and 9111 (for chat), <br />
**Remote admin: ssh 22, or rpd 3389<br />
=Be Prepared for the Worst=<br />
*Have backups ready <br />
*Practice recovery procedures ahead of time <br />
*Use a rootkit detector on a regular basis <br />
**Linux/MacOSX: <br />
***http://www.chkrootkit.org/ <br />
**Windows: <br />
***http://www.sysinternals.com/Utilities/RootkitRevealer.html <br />
=Moodle Security Alerts=<br />
*Register your site with Moodle.org<br />
**Registered users receive email alerts<br />
*Security alerts also posted online<br />
*Web<br />
**http://security.moodle.org/ <br />
*RSS feed<br />
**http://security.moodle.org/rss/file.php/1/1/forum/1/rss.xml<br />
<br />
=Miscellaneous Considerations=<br />
*These are all things you might consider that impact your overall security<br />
*Turn off opentogoogle, esp for K12 sites<br />
*Use SSL, httpslogins=yes<br />
*Disable guest access<br />
*Place enrollment keys on all courses<br />
*Use good passwords<br />
*Use the secure forms setting<br />
*Set the mysql root user password<br />
*Turn off mysql network access<br />
=Most Secure/Paranoid File Permissions=<br />
*The moodle folder<br />
**Owner apache user<br />
**Group apache group<br />
**Permissions 700 directories, 600 files<br />
*The moodledata folder<br />
**Should be placed outside the webroot, or restricted via .htaccess file<br />
**Owner root<br />
**Group apache group<br />
**Permissions 750 directories, 640 files<br />
*Reference forum thread http://moodle.org/forum/discuss.php?d=36185</div>Moorejonhttps://docs.moodle.org/20/en/index.php?title=Administrator_documentation&diff=5130Administrator documentation2006-02-10T21:38:24Z<p>Moorejon: </p>
<hr />
<div><p class="note">'''Note for contributors:''' Design and/or style improvements to this page are welcome :-)</p><br />
<br />
== Site management ==<br />
<br />
==== Installation ====<br />
<br />
*[[Installing Moodle]]<br />
*[[Windows installation]]<br />
*[[Installation FAQ]]<br />
*[[Installing AMP|Installing Apache, MySQL and PHP]]<br />
*[[Upgrading|Upgrading Moodle]]<br />
<br />
==== Configuration ====<br />
<br />
*[[admin/config|Variables]]<br />
*[[admin/site|Site settings]]<br />
*[[Themes]]<br />
*[[admin/lang|Language]]<br />
*[[admin/modules|Modules]]<br />
*[[admin/blocks|Blocks]]<br />
*[[admin/filters|Filters]]<br />
*[[admin/backup|Backup]]<br />
*[[admin/editor|Editor settings]]<br />
*[[admin/calendar|Calendar]]<br />
*[[admin/maintenance|Maintenance mode]]<br />
<br />
==== Performance ====<br />
<br />
*Please see [[Performance]]<br />
*[[Large installations|List of large Moodle installations (1000 or more users)]]<br />
<br />
==== Security ====<br />
*[[Security]]<br />
<br />
==== See also ====<br />
<br />
*[[Administration FAQ]]<br />
*[[Backup FAQ]]<br />
*[[Block layout]]<br />
*[[CVS|CVS documentation]]<br />
*[[Email processing]]<br />
*[[Messaging]]<br />
*[[Migration]]<br />
*[[Search engine optimization]]<br />
*[[Presentations]]<br />
*[[Moodle manuals]]<br />
*[[Using Moodle book]]<br />
<br />
== Users ==<br />
<br />
*[[User Authentication|Authentication]]<br />
*[[admin/uploaduser|Upload users]]<br />
*[[admin/enrol|Enrolments]]<br />
*[[admin/admin|Assign admins]]<br />
<br />
==Course management==<br />
<br />
*[[Course Categories|Course categories]]<br />
*[[Metacourses]]<br />
<br />
[[Category: Administrator]]</div>Moorejon