I created a backup with just one forum plus user/userdata. I transferred the file to the Site Files on a different site.
My intention was to restore into an existing course. When I restore I don't get that option - just restore to new course or to "current course". Current course presumably means the front page.
This isn't good... any thoughts what's going on here? I'm signed in as admin by the way, so I should certainly have the rights.
IIRC there was also an issue with not being able to select the category for courses restored from that location. Cold they be linked - both of these limitations are present for the teacher role.
Edit: Here's the issue MDL-15355
Ref. my Teacher role comment. Logged in as Admin I get New Course as an option, so perhaps not.
Edit: Here's the issue MDL-15355
Ref. my Teacher role comment. Logged in as Admin I get New Course as an option, so perhaps not.
Seems that when the choice is to
a) leave it alone
b) fix it properly
c) half break it
we picked this one:
// NOTE: SITEID is prevented as a source for restoring because it's public area and we must encourage admins
// to avoid using it as a "repository" for courses storage.
Except it isn't prevented - it's just screwed up enough to be weird and confusing.
Thanks for protecting me from my own stupidity
a) leave it alone
b) fix it properly
c) half break it
we picked this one:
// NOTE: SITEID is prevented as a source for restoring because it's public area and we must encourage admins
// to avoid using it as a "repository" for courses storage.
Except it isn't prevented - it's just screwed up enough to be weird and confusing.
Thanks for protecting me from my own stupidity
Hi Howard et all,
after fighting a lot with MDL-19163 where various variables must be controlled (cancreatecourse capability, number of courses where the course can be restored, origin of the backup file...), I ended with the approach commented here.
And after testing all combinations it seems to be working ok. And yes, to prevent admins to use site files as one repository of backup files is, IMO, a basic security measure. That is a public area and any file there can be downloaded by any user!
So, if you want to restore to existing course... then simply get used to copy the backup file to that course. it's simpler and way more secure. In fact I was tempted to prevent restoring to new course too but finally left that option enabled for "cancreatecourse" users.
Apologises if that causes problems to the routine used by you to restore courses, sincerely, but I really think it's a minor-minor effort to change that routine as commented above.
Finally, it's a pleasure to continuously be protecting you (not from your own stupidity) but from some dangerous uses.
Ciao
PS: So, I'm going to:
1) Close MDL-19246 as dupe/clone/whatever of MDL-19163
2) Try to fix MDL-15355 (the select categories problem). I've had that in mind since ages ago but always get lost in my maremagnum of bugs.
3) Add one notice in the last page before restore happens, commenting about going to restore over SITE.
4) Try to find where in Docs that behaviour can be explained and document it... Helen any idea?
after fighting a lot with MDL-19163 where various variables must be controlled (cancreatecourse capability, number of courses where the course can be restored, origin of the backup file...), I ended with the approach commented here.
And after testing all combinations it seems to be working ok. And yes, to prevent admins to use site files as one repository of backup files is, IMO, a basic security measure. That is a public area and any file there can be downloaded by any user!
So, if you want to restore to existing course... then simply get used to copy the backup file to that course. it's simpler and way more secure. In fact I was tempted to prevent restoring to new course too but finally left that option enabled for "cancreatecourse" users.
Apologises if that causes problems to the routine used by you to restore courses, sincerely, but I really think it's a minor-minor effort to change that routine as commented above.
Finally, it's a pleasure to continuously be protecting you (not from your own stupidity) but from some dangerous uses.
Ciao
PS: So, I'm going to:
1) Close MDL-19246 as dupe/clone/whatever of MDL-19163
2) Try to fix MDL-15355 (the select categories problem). I've had that in mind since ages ago but always get lost in my maremagnum of bugs.
3) Add one notice in the last page before restore happens, commenting about going to restore over SITE.
4) Try to find where in Docs that behaviour can be explained and document it... Helen any idea?
Hi Eloy,
What it needed/needs was an extra line in the UI explaining what was going on. It's not your fault, but I spent most of the day negotiating getting a huge backup file uploaded to the site files of a site I was not the (server) administrator of only to find it would not work for - as it turns out - a completely arbitrary reason. You should have heard the bad language
Part of me says that if I want to get all my courses stolen then it's up to me
I still feel it's a poor decision. I almost never restore one course into another (the thing I was prevented from doing). On the other hand, I restore backups to new courses all the time from the site files - which I *can* do. It can very well be used as a repository for course backups. I don't see how this "feature" achieves what it promises. It would have been more logical to prevent restore from the Site Files altogether, IMHO.
Sorry
What it needed/needs was an extra line in the UI explaining what was going on. It's not your fault, but I spent most of the day negotiating getting a huge backup file uploaded to the site files of a site I was not the (server) administrator of only to find it would not work for - as it turns out - a completely arbitrary reason. You should have heard the bad language
Part of me says that if I want to get all my courses stolen then it's up to me
I still feel it's a poor decision. I almost never restore one course into another (the thing I was prevented from doing). On the other hand, I restore backups to new courses all the time from the site files - which I *can* do. It can very well be used as a repository for course backups. I don't see how this "feature" achieves what it promises. It would have been more logical to prevent restore from the Site Files altogether, IMHO.
Sorry
Once again, agree, Howard.
I should have been more "radical" and prevent restore to new courses too, so then, once and for all, restoring from SITE files will be 100% out (but for restoring the frontpage course itself, of course). 100% agree (in fact I'm not sure why I ended with it being allowed, because I remember having it disabled completely in my dev box). Surely it got lost in the middle of all the tests.
Apart of that, I really think that any other problem / objection is simply one "change-your-workflow" thing, not really complex to do. About the "if courses are stolen it's up to me" well, it's up to you and up to Moodle. Any attempt to minimize risky practices is Moodle responsibility IMO.
In any case, at this point, I can see 2 possible solutions, while trying to minimize the existence of backup files in site area:
1) Prevent ALSO restoring to new course. Point.
2) Prevent ALSO restoring to new course BUT create two new config.php variables (call them, $CFG->restore_fromsite_toexisting and $CFG->restore_fromsite_tonew) that will switch default behaviour.
And of course, it's the 3rd solution, that will cause those files to continue being abused:
3) Revert to pre 1.9.5 approach, allowing to restore to existing (and new) courses again from site files.
My personal vote goes to 1) but if people agrees that 2 or 3 is better, I've not problem at all re-implementing it (though I wouldn't recommend that abuse of site files at all).
I'm pinging some people about this to get more opinions in the arena. Sure we can end with the best solution.
Thanks for your insistence, forcing me to rethink the thing a bit more, Howard (btw, I hate cats! - nah, just joking)
Ciao
PS: For reference, MDL-19246 is the related bug and MDL-19163 the cause.
I should have been more "radical" and prevent restore to new courses too, so then, once and for all, restoring from SITE files will be 100% out (but for restoring the frontpage course itself, of course). 100% agree (in fact I'm not sure why I ended with it being allowed, because I remember having it disabled completely in my dev box). Surely it got lost in the middle of all the tests.
Apart of that, I really think that any other problem / objection is simply one "change-your-workflow" thing, not really complex to do. About the "if courses are stolen it's up to me" well, it's up to you and up to Moodle. Any attempt to minimize risky practices is Moodle responsibility IMO.
In any case, at this point, I can see 2 possible solutions, while trying to minimize the existence of backup files in site area:
1) Prevent ALSO restoring to new course. Point.
2) Prevent ALSO restoring to new course BUT create two new config.php variables (call them, $CFG->restore_fromsite_toexisting and $CFG->restore_fromsite_tonew) that will switch default behaviour.
And of course, it's the 3rd solution, that will cause those files to continue being abused:
3) Revert to pre 1.9.5 approach, allowing to restore to existing (and new) courses again from site files.
My personal vote goes to 1) but if people agrees that 2 or 3 is better, I've not problem at all re-implementing it (though I wouldn't recommend that abuse of site files at all).
I'm pinging some people about this to get more opinions in the arena. Sure we can end with the best solution.
Thanks for your insistence, forcing me to rethink the thing a bit more, Howard (btw, I hate cats! - nah, just joking)
Ciao
PS: For reference, MDL-19246 is the related bug and MDL-19163 the cause.
Eloy - I have two dogs as well. Does that help?
Your work-flow argument is, of-course, correct. But... that only applies if you know about it. Please ask your self if you think a user should *expect* these restrictions! They are just not logical - having *no* restore in Site Files is logical but just *some* random restrictions feels like it was just done to annoy people. It annoyed me anyway
I understand what you are trying to do but I *really* don't think crippling the functionality was ever the answer. *If* (and I use that word deliberately) the Site Files being open is an issue then I don't think it should be fixed by restricting functionality within it. This will always come down to arbitrary decisions that will upset people's days.
My wish would be to remove any such restrictions (option 3) and then to change the styling or add warnings to the site files to remind admins the area is open.
I'd be really interested to understand why it was considered that *just* restricting restore to an existing course (a relatively little used feature) would make the slightest difference.
What's happening here is the designers making a bad decision - "unrestricted files area" - and then making the user pay for it - "making *arbitrary* restrictions therein".
Oh.... and don't think I've forgotten about not being able to select a category for the new course from site files
Your work-flow argument is, of-course, correct. But... that only applies if you know about it. Please ask your self if you think a user should *expect* these restrictions! They are just not logical - having *no* restore in Site Files is logical but just *some* random restrictions feels like it was just done to annoy people. It annoyed me anyway
I understand what you are trying to do but I *really* don't think crippling the functionality was ever the answer. *If* (and I use that word deliberately) the Site Files being open is an issue then I don't think it should be fixed by restricting functionality within it. This will always come down to arbitrary decisions that will upset people's days.
My wish would be to remove any such restrictions (option 3) and then to change the styling or add warnings to the site files to remind admins the area is open.
I'd be really interested to understand why it was considered that *just* restricting restore to an existing course (a relatively little used feature) would make the slightest difference.
What's happening here is the designers making a bad decision - "unrestricted files area" - and then making the user pay for it - "making *arbitrary* restrictions therein".
Oh.... and don't think I've forgotten about not being able to select a category for the new course from site files
Howard,
please, don't repeat your arguments about current implementation being "incomplete" once and again. I agree, 100%.
That's the reason I wrote above the 1 & 2 alternatives (both forbidding restore from site files *completely* by default). And then, the 3rd alternative that is about keeping if 100% allowed again.
Also, Site files aren't bad (or dangerous) per se. In fact they are really useful to store public files, like images, or any sort of document to be offered publicly.
The (potential) danger begins when backup files (containing tons of privacy information) is stored in that public area. And, after some years accessing continuously to dozens of sites... I can ensure that people is using Site files in that (potentially) dangerous way. And always I've asked the reply has been "because is easy to restore from there". So restore is, for sure, the main reason causing people to use site files in that way. And, sadly, the workaround for admins exists and is absolutely easy (copy those backup files to any other course area). Good!
Hence my +1 to prevent restore from site files *completely*, noticing about that change everywhere, of course (release notes, restore process, sec. report...). i.e. alternative 1) above.
Ciao
please, don't repeat your arguments about current implementation being "incomplete" once and again. I agree, 100%.
That's the reason I wrote above the 1 & 2 alternatives (both forbidding restore from site files *completely* by default). And then, the 3rd alternative that is about keeping if 100% allowed again.
Also, Site files aren't bad (or dangerous) per se. In fact they are really useful to store public files, like images, or any sort of document to be offered publicly.
The (potential) danger begins when backup files (containing tons of privacy information) is stored in that public area. And, after some years accessing continuously to dozens of sites... I can ensure that people is using Site files in that (potentially) dangerous way. And always I've asked the reply has been "because is easy to restore from there". So restore is, for sure, the main reason causing people to use site files in that way. And, sadly, the workaround for admins exists and is absolutely easy (copy those backup files to any other course area). Good!
Hence my +1 to prevent restore from site files *completely*, noticing about that change everywhere, of course (release notes, restore process, sec. report...). i.e. alternative 1) above.
Ciao
Ok... I think we are talking about this from a slightly different angle.
I've been frustrated with this behaviour since we first started using 1.9. We thought it was a bug! And why wouldn't we? There's no notices or warnings. You can't add restrictions like this without also having a clear warning within the UI. You just can't. That's my problem. I've wasted loads of time being frustrated by this "feature". What about the thousands of users who don't come near these forums? They'll just think it doesn't work properly - that's what I worry about.
If we don't want restore to work from the site files then disable it - otherwise it has to work like everywhere else. I don't care which but the present situation is just weird. I'm repeating myself again, I know
I've been frustrated with this behaviour since we first started using 1.9. We thought it was a bug! And why wouldn't we? There's no notices or warnings. You can't add restrictions like this without also having a clear warning within the UI. You just can't. That's my problem. I've wasted loads of time being frustrated by this "feature". What about the thousands of users who don't come near these forums? They'll just think it doesn't work properly - that's what I worry about.
If we don't want restore to work from the site files then disable it - otherwise it has to work like everywhere else. I don't care which but the present situation is just weird. I'm repeating myself again, I know
Surely it's a bug (an incomplete implementation at least), yup. Else we wouldn't be here discussing about it, hehe.
"If we don't want restore to work from the site files then disable it" That sounds like 1), isn't it?
Ciao
"If we don't want restore to work from the site files then disable it" That sounds like 1), isn't it?
Ciao
Oh, no!
his Majesty has talked, both in MDL-19246 and MDL-19163. And his opinion is about to:
- keep it working as used to be before 1.9.
- improve the warning in the page making it explicit for backups
- add one check to security report looking for zip files there.
And he has voted +100!. I guess there aren't 100 Eloys out there to vote against that at all. So, finally I will do that way, oki?
Thanks for the discussion and feedback, Howard and Co, ciao
his Majesty has talked, both in MDL-19246 and MDL-19163. And his opinion is about to:
- keep it working as used to be before 1.9.
- improve the warning in the page making it explicit for backups
- add one check to security report looking for zip files there.
And he has voted +100!. I guess there aren't 100 Eloys out there to vote against that at all. So, finally I will do that way, oki?
Thanks for the discussion and feedback, Howard and Co, ciao