really I don't think that using "moodle/user:create" neither "moodle/backup:createusers" is the proper solution. For me there are more "variables" is this problem. Let me explain the thing with one simple use-case:
Imagine server "A", with course "C" and student "S" enrolled (and with forum posts and other activity on it).
Teacher makes backup of course "C". Obviously it will include information of user "S" plus all his forum posts.
Then, for any reason, student is "deleted" from server A (so his login is changed along with other personal information), although forum posts and related info continues there, associated with the "deleted" user.
Then, teacher tries to restore backup into a new course, or into the same course (A) but deleting data first.
At this point, student "S" won't be found anymore in the server (check is performed by login - another problem - that has been trashed by the deletion), so restore MUST re-create it or, later in the process, when restoring forum posts, there won't be any user to link the info to). If we rely on any capability to decide if users will be created or no, we can easily end with non-restorable information. So, simple check isn't enough at all (nor for restoring in a different server nor for restoring in the same server, it's important to note that the problem can happen in any server, as the use case above demoes).
So, IMO, we can follow only 2 "safe" approaches:
- - The radical one: Preventing to restore ANY user related-info if user lacks the "moodle/user:create" (or "moodle/backup:createusers") capability. Note I'm not talking only about to prevent user creation BUT about to prevent restore of ANY user-related info (forum posts...) what can lead to a BIG loss of functionality for, say, 95% of sites. Of course, it's 100% safe, because now new users will be created nor information will be "orphaned". This is the approach we recently followed when restoring backup files containing mnet users (
MDL-17009) that now are only allowed to "moodle/user:create" users. Of course, we followed that approach for mnet users because it only affects "0.0001%" of sites (those using MNET). The question is if the same approach is extensible to all course backups.
- - The correct one: It involves to pre-check in the early steps of restore (before performing the restore of activity itself), if all the users to be added already exist in destination server. If that pre-check passes, then restore can continue because we have assured that all the activity will be properly linked to existing users, hence nothing will became orphaned. Obviously this pre-check will be performed when the user misses the "moodle/user:create" (or "moodle/backup:createusers") capability only. Users able to create users don't need the check at all. But we have two big problems with this pre-check: First of all, it doesn't fit well in current backup/restore architecture (it will be really hackery to introduce such a check). And second, we need to improve our algorithm of detecting existing users (see MDL-15598 for example), because current match by "login" is really inaccurate).
So... summarising, we have two alternatives:
- Completely prevent restoring backup files with user info to users missing the "moodle/user:create" (or "moodle/backup:createusers") capability. Easily doable, although perhaps the default for teachers, for better BC should be "moodle/backup:createusers" => allowed.
- Implement a complete user pre-check with an stronger match than the current one. More complex to implement but also tons better solution.
Sorry but the long comment, just trying to explain that it isn't only a matter of adding one capability (unless we want to be radical). Please comment, ciao