Backup roles 1.7

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Backup

Backup should be modified in two stages:

1. Calculating users to be included: It's controlled by the user_check_backup() function. Such function calculates the users to be included (based on whatever the teacher/admin has selected previously in the backup forms. All those users are stored in the backupable_users variable (an array of user-ids). No need to be modified, the logic is the same.

Then, beginning in line 48 of backuplib.php, we iterate over each element in that variable, calculating which roles (in the sense of old roles) every user has. This part of code (3-4 queries per user) fshould be replaced with the proper select/function that returns the new roles each user has (exclusively in the COURSE context!). This list, hopefully one array, should be serialised and saved to $backupids_rec->info (line 77), so all those info will be inserted to the temporal backup_ids table.

One notable exception is that, some of the calculated users can have 0 roles in the CONTEXT (unenroled users, old teachers...). This is because all those users have had some interaction in the course (forum post...) but now, for any reason, they don't belong to the course anymore. And, to keep information consistent, we need to restore such users too (with some sort of special virtual role assigned (currently such role is called needed and it must be added to the array of roles (current behaviour) or just leave such array empty. Note that such needed role is just one interim role used to know how to backup and restore such user later, not an official role at all.

2. Writing users to .xml file: Good news are that, since the beginning, the moodle.xml backup file contains one <ROLES> section inside each <USER> entry. Exact structure is:

<USERS>

<USER>

<ROLES>

<ROLE>

XML output for users is controlled by the backup_user_info() function. After printing all the user attributes, in line 1095, the process of writing the ROLES section starts. The $user->info variable must contain the serialised array of roles of the user (plus the needed virtual role named above). After de-serialising such array, if the user has any role, we'll start the <ROLES> tag, adding one <ROLE> tag for each role in the array.

Inside each element of those <ROLE> tags, currently we write all the old info (fields) from the old user_xxxx tables. As those tables are out, we only have to write the role name and, if I'm not wrong, the last access information (gathered, if present, from the new user_lastaccess table). Note that users with the needed virtual role are also exported.

With these 2 simple modifications, backup should be able to export new roles without problems.

Two important comments/questions:

a) Is it needed to export capabilities? If so, strategy above should change slightly.

b) How is going to be be the matching strategy on restore? Just by role name? It could cause some awful collisions depending of the name of the roles in the destination server.

c) Are role-names constant? I.E. the legacy student, teacher... roles are fixed names or are they localised for each language (I really hope they won't change by language, but just to be 100% sure).

d) Also, I would suggest to change the needed virtual role name to something more difficult to be used as name (to avoid potential collisions if the role name is going to be the matching strategy. For example: needed_backup_int_role or something similar.

Backup:

1. Calculate all the roles to be exported by using get_roles_used_in_context() on each module within the course and adding them up. Contexts searched are course, block and activity modules.
2. Calculate all the course, block and module roles for each user. Save them to the backup_ids table.
3. One unique ROLES section defining all the roles completely (with capabilities and level)
4. One ROLES section inside each USER defining the granted roles with their context. It's possible to have users without roles at all (unenrolled, or perhaps users who have access to the course via a category role_assign).
5. One ROLES_OVERRIDES section inside each context (course, module, block) to annotate overrides

Restore:

1. Restore the main ROLES section (3) completely!
2. Restore users, saving assigned roles to interim backup_ids tables.
3. When restoring course/module/block info, assign context roles to users.
4. When restoring course/module/block contexts, restore the overrides.