We were recently tasked with an Elgg project that requires forum discussions to behave like mailing lists. There's already a community contributed plugin that does something similar but doesn't quite meet the client's required specifications, notably with regards to permissions.
During the initial design, the client mentioned that we should think about reusability since the system might require other functionality that makes use of incoming emails in the future. So instead of just coding a plugin that will take care of discussions via email I decided to write a plugin that can handle incoming emails in a generic way and then trigger plugin hooks. The different plugins will then be responsible for implementation on how to handle the incoming email.
We recently posted about our project that implements Single Sign-On between Moodle and Elgg using Moodle Network (MNET). We wrote an Elgg plugin that extends the mnet-lib PHP library as part of this implementation. This early version of the plugin allows Elgg to function as an Identity Provider (IdP) so that its users can SSO to moodle. The current implementation assumes that ELGG is the authorative system. It doesn't have the capability to act as Service Provider. We expect to be doing a great deal more work to extend this plugin in its early stages so stay tuned!
About two weeks ago, a client raised an issue with their moodle installation. The client wanted course teachers to be able to take LAMS activites instead of just being allowed to author them. Then just this week, another client wanted to suppress the emails sent to course teachers when a student answers a quiz activity in moodle.
Both these issues are related in a way since the code logic that determines who can take a LAMS activity and the code for who are notified of quiz submissions both rely on checking moodle roles and capabilities. If you're familiar with moodle, then you'd be aware of the different roles that can be assigned to a user both on the site level and on the course level. What some people miss is that there are capabilities as well that's assigned to each of these roles. In order to resolve the issues that the clients raised without modifying the code, I needed to override these role capabilities so that they would behave as to how the client wants them to.
I'll outline here the steps of what you need to do to change the default roles capabilities in case you are faced with a similar problem.
To change the top-level role capabilities:
Solution Grove is in the process of testing an installation of the XO School Server (XS) of the OLPC project. Since I don't have an XO laptop, I needed to emulate one. I'm already running several virtual machines using VirtualBox so it makes sense that I go that route for an emulated XO.
I've outlined below the steps I did to emulate XO on VirtualBox. The steps here will most likely work with VMWare as well just by changing VirtualBox specific steps to their VMWare counterparts. These were researched and accumulated on the wiki.laptop.org and sugarlabs.org wiki pages. Some parts are copied verbatim and attribution go to their original authors.
In an earlier post, I wrote about how to properly integrate Adaptive Curriculum Activity Objects inside Moodle. After having success with that, the client now needs to have the activity object as part of a LAMS sequence.
The approach I came up with is to have the URL to the scorm activity created as a resource in the LAMS sequence. This particular client's LAMS server is in a different domain and port than the Moodle server and it doesn't satisfy the requirements of JavaScript's Same Origin Policy. This restriction presents a minor issue when launching the resource in a framed LAMS window. The only way to integrate it properly within LAMS is to have it launch in its window.
Solution Grove has a client who wanted to try out Adaptive Curriculum's (AC) Activity Objects (AO) inside Moodle. This initially sounded trivial since they provide SCORM compliant packages and I thought it was easy as just creating a SCORM activity for the AO. It turned out that AC's AOs are not standalone and they require authentication when installed on third party servers. Their objects use standard SCORM API calls for getting the user and session information then use these values to authenticate. The first part's the easy one since I don't need to write any code for that because Moodle already has API for SCORM 1.2.
The problem I encountered was that the authentication method used by AC needs to be run in a stateless manner through a server-to-server HTTP post using the user and session information that originated from the third party server (in this case, the moodle installation). This presents a problem for server-to-server communication because in moodle, the session id for the user is stored in a cookie and we will only be able to get that cookie if the script is run in the browser where it was issued. At this point, we are now in contact with AC to ask a few questions so that I can proceed implementing a code to support their AOs.
In order for us to track a one-to-one relationship between a Moodle course and an Elgg community we first need to create a mapping table. The table definition I used is as follows:
The eportid column corresponds to the Elgg community id for a particular course; the courseid is the one that tracks the Moodle course.<TABLE NAME="block_eportfolio_course_map" COMMENT=""> <FIELDS> <FIELD NAME="id" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" SEQUENCE="true" ENUM="false" NEXT="courseid"/> <FIELD NAME="courseid" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" PREVIOUS="id" NEXT="eportid"/> <FIELD NAME="eportid" TYPE="char" LENGTH="128" NOTNULL="true" SEQUENCE="false" ENUM="false" PREVIOUS="courseid"/> </FIELDS> <KEYS> <KEY NAME="primary" TYPE="primary" FIELDS="id" COMMENT="Primary key for block_eportfolio_course_map" NEXT="courseid"/> <KEY NAME="courseid" TYPE="foreign" FIELDS="courseid" REFTABLE="course" REFFIELDS="id" NEXT="courseid_uniq" PREVIOUS="primary"/> <KEY NAME="courseid_uniq" TYPE="uniq" FIELDS="courseid" PREVIOUS="courseid"/> </KEYS> </TABLE>
Since our code already supports single sign-on, we just add to that to track whether an Elgg community needs to be created. Let us reuse the signupredirect.php page and just add an extra variable that tells the system to create a corresponding community. The significant section is as follows:
The end result is a custom e-portfolio block that presents the following user experience:
As part of Solution Grove Blog's facelift, we added links to "share" the content to different social web communities. We already have the standard "Digg" and "del.icio.us" links in most of our client sites and we initially thought of putting this in our own blog. However, while browsing other blogs, I came across a niftier implementation. It's a free script provided by ShareThis. All you have to do is 1) register, 2) customize your "Share This" link using their "button builder", and 3) copy the code to your page or site template.
A few weeks ago, I posted how Solution Grove implemented Moodle to ELGG Single Sign-On. That was only the first phase. The client also needed it to seamlessly auto-create users on ELGG using credentials from the user's Moodle account. We searched for a solution for this and found his ELGG-WebCT integration solution from Aperto Elearning Solutions. Even though the other component was WebCT, it was still interesting to us as the concept is similar - the user is automatically created on the ELGG side. Solution Grove emailed Aperto and their contact person was kind enough to point to us the Aperto download server, where the code can be downloaded, and added a few tips in the email as well.
The assumption is that Moodle and ELGG were already properly installed and is confirmed to be working.
Here are the steps:
Subscribe to notificaitons