Hi,
I am currently trying to update my groupware module (soon to be contributed) so it uses the moodle groups mechanism, and I wondered if any developers out there could point me towards the steps I would ned to take to allow only people in a vertasin group to see a certain groupware.
I assume I have to add some code to the add activity page when the groupware is first created, and add some checks similar to isteacher() to the groupware code, but this is as far as I have got.
If any developers have any advice on the best,m or most "moodley" way to do this, it would be gratefully received.
Many thanks,
Chris.
Just to clarify my goal here. I would like to assign groups in a course, and then each group can only see the activities that are assigned to that group.
Is this actually possible with moodle, or would the activities all have to be visible, and group permissions applied when an attempt to access the activity is made?
Many thanks,
Chris,
Is this actually possible with moodle, or would the activities all have to be visible, and group permissions applied when an attempt to access the activity is made?
Many thanks,
Chris,
The latter only.
For coding, look at some of the standard modules ... you only need to add a few lines usually.
For coding, look at some of the standard modules ... you only need to add a few lines usually.
Thanks for the reply, but I cannot sem to see how the modules work with group settings. I have tried adding chat/quiz/forum/assignment, but cannot see where to assign them to a group?
I cannot see anywhere in the settings for these activities where I can tell the activity instance which groups can participate in it.
??
chris.
I cannot see anywhere in the settings for these activities where I can tell the activity instance which groups can participate in it.
??
chris.
You can't do that, that's why I said "the latter only" (ie the last thing you said).
Heh, I remember Moomintrolls.
Heh, I remember Moomintrolls.
My father was a moomin you see.
I've added group support by adding a group select when adding a new groupware to a course. This adds the group field to the groupware table, so I can later test if a student is a member of the group to which this groupware is assigned.
This select reads in the groups in the current course, and simply assigns a group id to the groupware when it is created.
Now does this seem consistent with the moodle way of doing thing? as it seems to fit my application needs perfectly...
Though after adding a group field to my groupware table, and a group select to my form in mod.html, moodle returns "Could not add a new instance of groupware"
it gets the following object...
stdClass Object
(
[name] => gfgf
[group] => 4
[course] => 2
[coursemodule] =>
[section] => 0
[module] => 14
[modulename] => groupware
[instance] =>
[mode] => add
[timemodified] => 1093268274
)
Is it the missing coursemodule and instance that is the problem? I would have thought these were auto generated?
Chris( a moomin).
I've added group support by adding a group select when adding a new groupware to a course. This adds the group field to the groupware table, so I can later test if a student is a member of the group to which this groupware is assigned.
This select reads in the groups in the current course, and simply assigns a group id to the groupware when it is created.
Now does this seem consistent with the moodle way of doing thing? as it seems to fit my application needs perfectly...
Though after adding a group field to my groupware table, and a group select to my form in mod.html, moodle returns "Could not add a new instance of groupware"
it gets the following object...
stdClass Object
(
[name] => gfgf
[group] => 4
[course] => 2
[coursemodule] =>
[section] => 0
[module] => 14
[modulename] => groupware
[instance] =>
[mode] => add
[timemodified] => 1093268274
)
Is it the missing coursemodule and instance that is the problem? I would have thought these were auto generated?
Chris( a moomin).
Got it.
Group was a used variable name, renaming it to moodle_group fixed the problem....
Group was a used variable name, renaming it to moodle_group fixed the problem....
Hi Chris,
an activity should not be "assigned" to a particular group. Rather the activity is assigned to the course and afterwards on the course homepage you can select the group mode of the activity. The group modes are:
- No groups means there is only on copy of the activity for all students
- Visible groups means that there is one copy of the activity for each group but students can also select to see some information about the activities in the other groups via a drop-down menu.
- Separate groups means that there is one copy of the activity for each group and students can only see the activity for their own group.
None of this is specified when you add the activity. The groups mode is toggled later via the icons on the course home page.
Play around a bit with the existing Moodle modules to get a feel for it.
Hi Gustav.
The module I am writing has some special features, like connecting to a subversion version control server for storing its content etc... so each groupware must be unique, and usable by only one group. Some of the content that is dealt with by the groupware module is stored not in the moodle database, but on a remote subversion repository, so each groupware instance comes along with a folder_name (off the root of the repository) etc so in my case, I think it is best to have one groupware for each group.
I see how the groups in moodle work now, and I see why your comments were made, if it were not for the special nature of the module, I would agree completely.
Thanks for your reply, much appreciated.
Chris.
The module I am writing has some special features, like connecting to a subversion version control server for storing its content etc... so each groupware must be unique, and usable by only one group. Some of the content that is dealt with by the groupware module is stored not in the moodle database, but on a remote subversion repository, so each groupware instance comes along with a folder_name (off the root of the repository) etc so in my case, I think it is best to have one groupware for each group.
I see how the groups in moodle work now, and I see why your comments were made, if it were not for the special nature of the module, I would agree completely.
Thanks for your reply, much appreciated.
Chris.
Why not just connect to different repository subfolder name depending on the currently active group?
well, I would like a list of the available groupware's in the activities section, rather that one "groupware" activity who's content depended on the active group.
Some people may be a member of the developers group, and the class 1 group, and also want to look in the general groupware which is not assigned to any group, but which is visible to everyone in the course (like a standard activity) and I could not see a way of doing this with groups in moodle.
I am using the moodle groups functions, and the groups system, but just locking a groupware instance to a group when I create it.
However, I acept that I may have got the wrong end of a stick, this has happened before, and will happen again
thanks for your help
Some people may be a member of the developers group, and the class 1 group, and also want to look in the general groupware which is not assigned to any group, but which is visible to everyone in the course (like a standard activity) and I could not see a way of doing this with groups in moodle.
I am using the moodle groups functions, and the groups system, but just locking a groupware instance to a group when I create it.
However, I acept that I may have got the wrong end of a stick, this has happened before, and will happen again
thanks for your help
What do you mean by "Some people may be a member of the developers group, and the class 1 group"? Currently in moodle users can not be members of several groups. So it seems that your groups concept can not map onto the Moodle groups concept for this reason. All the other things you want (like having one activity visible to everyone and others only visible to the group) can be done with Moodle's standard groups mechanism.
Really!?!
This seems a little strange? why can a person not be a member of more than one group?
I presume courses have their own groups, so I could be a member of a group in one course, and a member of a diffrent group in another course?
Most groups concepts I have seen in systems development allow people to be members of as many groups as they like. Real life certainly works this way, and in this case, should moodle not follow these complexities and offr the flexibility of a person being a member of more than one group?
Confusedly,
Chris.
This seems a little strange? why can a person not be a member of more than one group?
I presume courses have their own groups, so I could be a member of a group in one course, and a member of a diffrent group in another course?
Most groups concepts I have seen in systems development allow people to be members of as many groups as they like. Real life certainly works this way, and in this case, should moodle not follow these complexities and offr the flexibility of a person being a member of more than one group?
Confusedly,
Chris.
Sigh ... yes groups could be more flexible, but they aren't. Not everything can be done already. 
However, groups are course based only. You can be in as many courses as you want, and be in any one group within each course.
For many applications where you want completely flexible groups, just adjust your thinking from "groups" to "courses". For example, there are many groups of people on this site, I've just made courses for them all, and people can join them as they wish.
However, groups are course based only. You can be in as many courses as you want, and be in any one group within each course.
For many applications where you want completely flexible groups, just adjust your thinking from "groups" to "courses". For example, there are many groups of people on this site, I've just made courses for them all, and people can join them as they wish.
Hence the three group settings that each activity can have. In your case they would translate to:
- none: groups are ignored and everyone sees one big repository
- visible: groups are there, but everyone can use the menu to get to other repositories (possibly with read-only access to the repositories of other groups)
- separate: each group only sees their own repository