Moodle

If you read the discussion, you will see that we discussed enhancing Upload users to allow assignment of roles in ANY context (not just System). This can be done by specifying Context type, context instance, and role short name. System would fall out as a special case.

I use Moodle in a corporate setting. We have two unique needs: (1) Supervisors need to view the grades of their employees; (2) HR department needs to view the grades of any/all employees. It would be great if we could automate this process of assigning these types of roles rather than doing it manually. We are a smaller mid-sized organization with 1600+ users. I can only imagine what organizations with 10,000+ users must think about this! Thank you.

Hi John and Richard et al.,

Please read my tracker number MDL-15391 and vote for it if it makes sense. It fits in here with yours in that I'm also wanting. I'm hoping the csv upload can include it from the top down also on import, ie, list a parent or supervisor and link them to their mentees. THis is more intuitive to me and helpful to me as I have teachers who have 30 students to track (but not teach) in moodle (separate moodle teachers teach our course). Thanks for reading whatever you vote.

James

We also need a way to know who is attached as mentee in moodle. I have now over 2000 users and when I attach them there is no way to know beforehand who I've already attached using the mentee feature. This would save time so I could focus only on those who need to be attached.

Once this mentee attachment process is automated then I would not need to know who was attached but for now the process of attaching them is extremely time consuming for me.

Assigning this to Martin for his consideration.

IMHO we should have an alternate upload_role_assignments format for this (mainly because current upload_user format is really overloaded with groups, courses...).

Just with username|useridnumber - courseshortname|courseidnumber|contextid - roleshorname|roleid should be enough.

Heavily checking everything, doing nothing if something is wrong and being able to revert (undo) any loaded file (i.e. unassign roles).

Ciao

Some references for this, to have them together:

• MDL-15391
• http://moodle.org/mod/forum/discuss.php?d=91436#p436787
• http://docs.moodle.org/en/Upload_users

Eloy - I am in agreement with you that keeping it separate is the way to go. Do you think that in terms of updating roles that we should be able to remove roles? It might be interesting to have a roles_log table that would have the userid, contextid, roleid, status (either added or deleted), timestamp and perhaps some type of id representing the uploaded file (perhaps filename and timestamp) . Having such a log would make it possible to do the roll back. Peace - Anthony

Hi Anthony,

my first idea was about to have such log file in DB, but after a while I thought it could be too much, mainly if we keep copies of the processed files (that's all we need to be able to revert loads, IMO). Note I think it's VERY important to prevent anything to be loaded if any error is found in the file (unexisting context/user...). That way, the whole "transaction" will be able to be reverted easily by processing the same file doing the opposite. Simple.

But yes, the log table is another interesting possibility that, for sure will allow more fine-grained control about when something was granted and possibilities to revert it. 100% agree.

Agree.

Eloy - I like the idea of storing the file. Would that go in the backupdata folder for the site? Peace - Anthony

Uhm... could be a good place yes (if it's safe, I don't remember the situation, from a security perspective, of that folder right now). Perhaps we could use an "exclusive" folder for that instead, out from normal site/course files, like we use to do with other Moodle bits (rss, sessions, upgradelogs...).

But if SITE/backupdata is safe, then it's safe to use it, yes! (note this will change dramatically in 2.0 and new file-areas).

Ciao

Eloy - I was taking a look at this issue of how to mass upload user roles. I think for maximum flexibility, I would require that the context level be specified in the text file. Here is what I am thinking for an initial step.

User (username or idnumber), Context Level (system, user, category, course), Context name/identifier, Role (shortname) For example,

admin1, system,, admin
teacher1, course, Math101, editingteacher
student1, course, Math101, student
student2, course, Science101, student
parent1, user, student1, parent
parent2, user, student2, parent
mathdean, category, Math, coursecreator
sciencedean, category, Science, coursecreator
ta1, course, Math101, teacher

This brings out what will likely be one source of confusion. Namely that a normal teacher has the shortname editingteacher whereas the non-editing teacher has the shortname teacher. I know there will be questions about this and personally think that teacher should have the shortname teacher and non-editing teacher should have the shortname noneditingteacher (IMO). I'm not sure of the implications of changing that at this point so we may just have to live with it.

For context levels we are excluding (for the time being) the options of group, module, and block since these would each require an additional course identifier (name or idnumber).

I believe (but would have to verify) that the context name/identifier for system is the front page (course.id=1 in most cases). The name/identifiers for the user context could be either username or idnumber. The name/identifier for category would be the course category name. However, we may want to omit this initially and give some consideration to how best to handle course categories. The problem I see is that the name is not a unique identifier of the course category and the user does not have a way of setting an idnumber that could uniquely identify it. Technically speaking, the user and course idnumber fields are not guaranteed to be a unique identifier which is something perhaps that we should begin to enforce if we are going to continue to develop the capability for folks to do mass operations by importing text files (which I think is very helpful for system administrators) and goes a long way in helping to import data from other systems. I'll create a tracker issue to create an idnumber field in course categories as I think it could be useful for folks. Similarly, we may want to consider an idnumber field for the groups table. Yet again, we should probably enforce the uniqueness of groups.courseid, groups.name if we implement this mass role assignment for groups. I see the idnumber field being less useful or necessary for the module and block context levels. The name/identifier for course could be shortname or idnumber.

So to summarize,
10 - SYSTEM - course.id (frontpage/site) - no context name/identifier required (can be anything (preferably blank) as it is ignored)
30 - USER - user.username or user.idnumber
40 - CATEGORY - course_categories.name
50 - COURSE - course.shortname or course.idnumber
60 - GROUP - groups.courseid, groups.name
70 - MODULE - course_modules.course, course_modules.module (looked up from modules.name)
80 - BLOCK - block_instance.courseid, block_instance.blockid (looked up from block.name)

I do not see as part of this bug allowing to create roles from CSV files so if a role name is not found it should be ignored with a warning/status message to the user indicating that that record was not processed.

Does this seem like a reasonable approach to setting up how the CSV file should be used? Does it provoke any comments, questions or concerns? Once we are agreed on the file we can begin looking at how to implement it so that we can handle the heavy checking and any reversions.

Peace - Anthony

Tim - I am not sure if this is the right issue, but the ability to upload role assignments via CSV seems like it would be related to the role usability work you have been doing so I am linking this issue to that and removing the link to MDL-17017 which focuses on courses related functionality. Peace - Anthony