Joomdle, cohorts and groups

(reposted after it went in the wrong place - I didn't realise that when you click "new topic" in a forum that the category automatically reverts to the first category in the list, I thought it would post in the forum where I clicked the link!)

First of all, a big thank you to the developers for creating Joomdle.

I'm currently preparing a site for a group of local charities that work in similar fields and occasionally interact. The goal is for them to have a standardised set of courses so that each organisation can (i) save costs by only having to prepare one set of courses to share between them and (ii) they all work on the basis of the same core information. This is accessed through a traditional frontend CMS that contains a variety of other features and tools.

What I would like to achieve from the LMS is for each organisation to have their own group/cohort. Each organisation will have their own manager who can add/delete/enrol/monitor grades etc for users within their own group/cohort only. They do not want other organisations to see their staff lists or other details. The role of Site Administrator should only really be needed to add courses that are accessible to everyone, add new organisations and assign the organisation management roles to the appropriate people.

The way we are trying to implement this is through a combination of Joomla, Moodle and Joomdle.

Currently, I have installed Joomla 3.2.1, Moodle 2.6.1, and Joomdle R 0.94.

The installation is working from the testing done so far. I now want to try and make it work in a certain way. While I have been poking around the settings and documentation with varying degrees of success, my question is whether anyone has found a "best practice" way of achieving something close to my goals..

The Joomla side of this seems straightforward (group management, varying levels of users) so my focus is on the Moodle/Joomdle side.

Moodle supports groups and cohorts - though cohorts seems to be the closest to the Joomla Group. It appears that I can also assign management functions (adding/removing members of cohorts) to a user without giving them the power to create or delete cohorts. I can also attach a cohort to a category, which will isolate it from cohorts in other categories.

On that basis, each organisation will have a separate category containing a cohort, managed by a user within that cohort. I envisage a non-editing teacher role with additional management rights for the cohort, with this role being allocated to the organisation's designated "manager" position. There's a bit more testing ahead to see if this works as expected, but the documentation suggests that it should.

So, in terms of process, the organisation manager will log in to Joomla and add a new user. That user should be created in Moodle and then placed into the same Joomla group, Moodle group and Moodle cohort as the manager - and all ideally automatically. To put it into pseudocode (which is always far easier to write than it is to implement :whistle: )

The Moodle user is created automatically, but does Joomdle support adding the user to the appropriate Moodle group and cohort? If not, is it a feature that is likely to be considered? Is this even the best way to achieve what I want to achieve?

Any thoughts or comments welcome - apart from "make a separate moodle for each of them and just share courses" because I've already suggested that and been told no

Hi.

To sum up: you cannot do what you want without adding features to Joomdle.

One note: as far as I know, there are no sitewide groups in Moodle, only cohorts.

Joomdle has a somewhat related featute: users can register other users as their children.
You could start from that to get what you want, but it would take quite some coding.

If you are interested in sponsoring such features, please write to development@joomdle.com

Thanks for the reply.

I've taken a slightly different approach after experimenting and I'm now using metacourses, with each organisation enrolling through a child course that has a custom role assigned - based on a non-editing teacher but with additional enrolment powers. This is providing a good chunk of the functionality I want, but still requires additional manual steps to configure.

I was trying to avoid custom coding but I'm not adverse to it. I'm also not adverse to sponsoring development, but not for this project as there's no money in it!

Time to open up the database and php and see what I can do :whistle:

> I was trying to avoid custom coding

Well, I was talking more about adding features to Joomdle, not having custom code for you only.

> sponsoring development, but not for this project as there's no money in it!

I already had thought about that, sice you talked about charities. Having that in mind, I could try to help anyway, if we think the features you need could be useful to other Joomdle users.

When you have more clear they route you want to take, please share your thoughts and needs, and we can see if it something we could do.

My apologies, I should have been clearer - even if I paid for code, I would ask for it to be made openly available because I'm already benefiting from the time and hard work that others have put it. I meant I was trying to avoid writing custom code myself!

While I certainly appreciate the offer, I should make it clear that there could be a commercial benefit later - this situation came about when I was discussing a speculative idea with someone involved with the charities, who then said "hey, we like that idea, do you think you could make it work for us?". They're getting it for free but if it works I might put this into a completely separate commercial project later.

Current goal

What I am trying to achieve is a "box" around each organisation - though they can share the course content, there is no knowledge, sight or interaction between the organisations. Inside their box, they can manage their own users without needing the administrator to become involved.

Some of these functions are purely Joomla settings, some are purely Moodle settings, but some fall in between and might be useful to tie into Joomdle - from my perspective anyway.

Useful to other users?

I think that developing some form of robust group-mapping between Joomla and Moodle might be useful - partly because Joomla seems to be the most logical place to handle user accounts as it is the initial starting point in the process, but mostly because Moodle has one of the most unfriendly user interfaces in the world so moving things to Joomla would be great.

It might even be nice for Joomdle to be able to tag (and create/synchronise) Joomla Groups as being moodle groups, moodle cohorts, or neither - or even as both, which would be particularly useful to me.

Current approach

Within Joomla, each organisation is assigned to a separate group ("orgname"). The group structure is member->editor->manager, though the editor role only applies to the Joomla content and is irrelevant to the moodle side of things.

Within Moodle, each organisation is assigned a cohort ("COHORT_orgname") and a group ("orgname").

I have created a custom role within Moodle called a "group manager". This is essentially a non-editing teacher with additional enrolment rights. A user within a group is assigned this role and becomes the "group manager" - if I use the term manager, please remember I mean this custom role not the Moodle Manager role.

Courses are created as meta courses. In order to make it available to an organisation, a child course is created (blank course that serves as an enrolment gateway) and the group manager is assigned to the course. The more I play with it, the less I think this may be necessary as the group functions should prevent the manager from seeing or dealing with other group members on the course, but this needs further exploration. Exactly how this will be implemented does not directly affect my goal with joomdle.

The group manager can see the available course and can enrol users individually or via cohort enrolment. The group manager can also see the grading and other key information.

Problems with current approach

At the moment, when the manager adds a new user, the site administrator then needs to add that user to the group and to the cohort. I do not want the manager to have the rights to assign groups as it introduces extra steps and requires them to have access to users and groups outside their organisation. The group and cohort are defined by the group of the manager and the naming convention was chosen to make it easier to link the two programatically, which makes this step ideal for automation.

When a manager enrols users, they still get to see all the users across the site. As I type, it occurs to me that I can disable manual enrolment and just allow cohort enrolment, which might resolve this, though this may not be suitable due to different course levels needed for different users (ie senior staff might need to take a higher level course on financial responsibility which would not be suitable for a normal volunteer).

Possible resolutions

Introduce a system, triggered by the creation of a new user, that adds the new user to the appropriate group and cohort in moodle. Logically I think I should try to fit this into the joomdle hooks for joomla/moodle user creation.

Introduce a conditional test in moodle - for example, test to see if it is the group manager who is calling for a list of users (such as when opening up the enrolment screen) and, if so, inject "AND user.groupid = groupmanager.groupid" into the WHERE clause of relevant SQL statements so that it only returns users in the same group. I've not read through all the code yet so I'm not sure if or where this would work, but some variation on this idea should be possible.

Summary

The basic idea is shared content but self-management - each organisation will have access to the shared courses, the ability to add their own users, and the ability to enrol their own users on whichever course they think appropriate for that user. The bit which causes problems is that each organisation wants to keep their own user lists private, so other organisations cannot see who works where, grades etc - though they all accept there will be a site administrator who can see everyone, they want to limit access as much as possible. While using groups and cohorts does allow much of this functionality, the process of linking users to groups/cohorts should be invisible to users, especially as they should never be allowed to access/assign a user to a different group/cohort.

How that gets implemented is up to me, with the key requirements being that (i) they want Joomla as a front end with moodle integrated, and (ii) they want it in one moodle instance rather than having separate moodle installations for each organisation.

Starting point for making this work

One of my options for a brute-force approach is to directly modify the database. Time for some psuedocode again!

The difficulty with this is that it skips a number of steps (such as setting up other fields in the rows properly), so I would prefer to work out how to call the "add to group"/"add to cohort" functions properly.

Having said that, the mdl_cohort_members table is quite straight forward and should only require the user/cohort ids and a timecode. Provided no other tables need to be updated when a user is added to a cohort (and it appears to be a simple linking table so I am hopeful that is the only table modified) then the first part of my goal appears reachable.

The groups_members table is a little more difficult as I can only guess at the function of the component field (though I suspect always putting "enrol_cohort" would work in this context, though it hardly makes for flexible coding) and I do not know what ItemID represents. I would again be surprised if another table needed to updated at the same time, but the ItemID suggests that something else is happening in the background.

It's also a matter of identifying the most appropriate entry point for injecting any code I come up with. The joomdlehooks plugin appears to handle the autocreation of a moodle user with onUserAfterSave() (joomdlehooks.php @ line 204). I'm thinking that the $reply from the call to create_joomdle_user can be tested to see if the call_method response is the XML_RPC_xxx error string and, if not, then auto-add the user to the appropriate Joomla group (based on the calling user's own group) followed by whatever code will add the newly-created user to the appropriate Moodle Cohort/Group. Where I am a little unclear is whether this function is being called only when a user self-registers (which will be disabled for this site) or when an existing user adds another new user.

Even with error checking in place, this still requires that groups with matching names are set up in both Joomla and Moodle properly, and ensuring that the naming structure for Cohorts is followed in Moodle. As those steps would be site admin steps and may only ever need to be done once (or rare updates if an organisation joins/leaves) this is overhead that I think is acceptable.

It all feels like it should be possible, it's just the pain of finding a stable way to make it work without rewriting enormous chunks. I have the luxury of not needing to make it flexible or extensible at the moment, I can hard code behaviour without needing to worry about adding options or controls. As long as it works in this current instance I'm happy - making it flexible and adaptive to different administrator needs is a much longer-term goal.

Thanks for the detailed explanation of your ideas.

Also, thanks for the notice about the commercial side. If me move on helping you with this for the charities, we can decide later what we do with the code. We have sometimes thought of building something similar to what you describe, to offer as a paid download or something like that.

So, my first thought is clear and the same as you: the more you can move to joomla, the better. Any other approach would require to modify core moodle code, which I don't think is a good idea.

A couple of assumptions/questions:
- Course managers are created by admins, and assigned to relevant groups

For now, I could think of the following, please comment and add any features you may think of:
* "Course manager" Component
Views/features in front end:
- User list / Add user
Add user would show a form to create user. When doing so, it would add the joomla user to the same group as the creator. Here it triggers the jcohorts plugin, to be discussed later
- List managed courses (those were user is group manager)
- Course functions: Enrol users / grades / lists to tasks to be done in moodle ...
Enrol users would only display users from the same group as the user

- Jcohorts component and plugin. This is something I worked on this week from old code after reading your first post.
The component backend lets you define joomla groups - moodle cohorts relationships.
The plugin calls joomdle web service in Moodle to add user to relevant cohort when user is saved.

Something similar could be done for groups if necessary.


If you are interested in researching this further, please write to antonio@joomdle.com, and we can start working on it :)

Antonio Durán wrote: A couple of assumptions/questions:
- Course managers are created by admins, and assigned to relevant groups

I think this would be the best way. The admin should create and control the overall structure and allocation of roles. Course managers are really there to handle the "day-to-day" tasks around student management.

In the charitable context, the side admin has no interest in knowing who has done what - it is for the course manager to make sure their staff have taken the appropriate courses. The site admin does not want or need to get involved, their role is simply to configure the groups/managers and setup the courses.

In the commercial context it is a little more involved. First, the site admin is the one with the power to award accredited points for passing the course, so they might not be interested in organising who takes a course, but once someone takes it they need to review the outcome to approve it. Second, the site admin wants to know how much in attendance fees to charge to the course manager. This feature is probably a key difference between a commercial/non-commercial version.

Antonio Durán wrote: For now, I could think of the following, please comment and add any features you may think of:
* "Course manager" Component
Views/features in front end:
- User list / Add user
Add user would show a form to create user. When doing so, it would add the joomla user to the same group as the creator. Here it triggers the jcohorts plugin, to be discussed later
- List managed courses (those were user is group manager)
- Course functions: Enrol users / grades / lists to tasks to be done in moodle ...
Enrol users would only display users from the same group as the user

If those features could be brought within Joomla, that would be fantastic. The only suggestion I might possible add is some kind of bulk addition - I know at least one of the organisations has about 100 people to add!

Antonio Durán wrote: - Jcohorts component and plugin. This is something I worked on this week from old code after reading your first post.
The component backend lets you define joomla groups - moodle cohorts relationships.
The plugin calls joomdle web service in Moodle to add user to relevant cohort when user is saved.

Something similar could be done for groups if necessary.

From an end-user perspective, I've been thinking about how cohorts could be used. My original plan was to basically to make a cohort and a group that mirrored each other. When I started to look again at how people would be using it, I realised this could still create a massive workflow for the manager.

For example, the charity that I work with has three basic categories - volunteers, paid staff, and management. All of them have to take a course on data security to protect clients' personal information. The volunteers only need to study to level 1, the paid staff to levels 1 & 2, and the management to levels 1 & 2 & 3, because each group has a different level of access to the computer systems holding the information.

My thinking is that the current cohort/group idea is still used as an "all users in the organisation" collection. I want to now look at whether it is feasible for each organisation to have a collection of additional cohorts that can be used to create logical enrolment groups, so a manager can associate them with a particular group ie volunteers, management, etc. I think this would be a task for the site administrator - the grouping could be agreed at the start, with the course manager making a request for an additional group.

It's very easy to have ideas. Implementing them is the tricky part. It's been a very, very long day and now I need to sleep, but I will spend some more time tomorrow looking at how it could logically fit together using as much of the existing Joomla/Moodle features as possible. If it is just a matter of mapping jGroups to mCohorts, then this could allow the power and logic of Joomla group management to control the relationships.

Antonio Durán wrote: If you are interested in researching this further...

I am! I am also careful of a number of things:

• I don't like encouraging someone to do something that helps me unless I am willing to put in just as much time and effort
• Just coming up with ideas for other people to make work doesn't really count as putting in any "time and effort"
• This isn't my day job! I can write code well enough to make basic things work in a rough way, but I do not write professionally or with much style.

My initial plan was to get something that worked "well enough" to get running now, then spend spare time over the next two or three months trying to make something more robust. I have about 5-7 days to work on the first stage, but the second stage might be a matter of using a few spare hours on a weekend.

Thanks for the additional info, and for sharing your concerns about making others work

As you talk about a very short timeframe (5-7 days) it is clear what we cannot have anything custom made by then, so I guess your plan to make something "good enough" first is ok, and then we can work on a replacement with more time.
Once you have the organization clear, even if it requires many manual tasks now, it will be just a matter of creating new code to better handle those tasks.

I think I will have some time this week, so I will try to start working on the basics. Once that is ready we can discuss how to move forward.

One comment:

> My thinking is that the current cohort/group idea is still used as an "all users in the organisation" collection. I want to now look at whether it is feasible for each organisation to have a collection of additional cohorts that can be used to create logical enrolment groups

I was thinking about this, and I think something like this should work:
- Have a "main group" for each organization
- Have child groups of the main group, representing the different "logical enrolment groups"

This project hasn't been abandoned or forgotten, just to let you know!

I sat down with the original group and walked them through their timeline and milestones. It was identified that this milestone could be pushed back as there actually wasn't enough content generated yet to make effective use of it. This lifted the time restraint that was only going to lead to heartache and quick fixes. We've now come to the conclusion "I'll carry on working on it, come back to me when you actually have something to use it with" with a provisional expectation of within the next one-two months :whistle:

As I continue to work on this project, I'll update the approaches being taken in case there are any useful ideas that people could use.

Due to a change in requirements for the commercial project (more specific content, access and group control among other things) I'm not entirely sure that I will be trying to route that through Joomla. That might end up as a custom platform, though that still leaves me with either (i) trying to talk to Moodle myself, which is outside of my knowledge at this time, or (ii) making my own single-purpose LMS, which is less scary to me than connecting to Moodle!

So, just an update so that you know I'm not a hit-and-run poster :laugh:

Thanks for the followup, I too started doing some work, and then had to stop because other more urgent things came in the way.

Please keep us informed. As you say, good ideas can appear on this discussion.