Talk:Cohorts: Difference between revisions
(New page: The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --~~~~) |
Ray Lawrence (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --[[User:Dan Poltawski|Dan Poltawski]] 23:50, 8 March 2010 (UTC) | The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --[[User:Dan Poltawski|Dan Poltawski]] 23:50, 8 March 2010 (UTC) | ||
It would be useful to expand the comments about replacing category enrolments. Assignment to a role for a category e.g. as course Creator is a method used extensively to provide delegated permissions by department, school etc. It would be a shame for this to be lost in 2.0. | |||
Will cohorts be role agnostic in the same way as course groups? | |||
The following is a frequently asked for use case that doesn't seem to be catered for in specification here: | |||
Site administrator (or others with relevant permissions) can allocate to a cohort e.g. cohort a, cohort b. | |||
The site administrator wants to hand over responsibility for allocating users to cohort a to a user in cohort a who has the necessary permissions. This user should not be able to access any other cohort or allocate users to them. Are the new capabilities granualar enough to facilitate this? --[[User:Ray Lawrence|Ray Lawrence]] 09:53, 31 March 2010 (UTC) | |||
Revision as of 09:53, 31 March 2010
The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --Dan Poltawski 23:50, 8 March 2010 (UTC)
It would be useful to expand the comments about replacing category enrolments. Assignment to a role for a category e.g. as course Creator is a method used extensively to provide delegated permissions by department, school etc. It would be a shame for this to be lost in 2.0.
Will cohorts be role agnostic in the same way as course groups?
The following is a frequently asked for use case that doesn't seem to be catered for in specification here:
Site administrator (or others with relevant permissions) can allocate to a cohort e.g. cohort a, cohort b.
The site administrator wants to hand over responsibility for allocating users to cohort a to a user in cohort a who has the necessary permissions. This user should not be able to access any other cohort or allocate users to them. Are the new capabilities granualar enough to facilitate this? --Ray Lawrence 09:53, 31 March 2010 (UTC)
