Details
Minor
Description
It is possible to be locked out from changing the "force download" and "window" settings for resources. Steps to reproduce:
1. Admin => Modules => Activities => Resource => Change Window from default "Same Window" to "New Window"
2. Edit any course => Add a resource => Link to a file or website => Change Window from "New Window" to "Same Window"
3. The Force download checkbox that was previously locked is now available. Set it to True. Save.
4. Edit the resource just created. Both "Force download" and "Window" fields are locked. If you wanted to change these settings, you would need to delete the link and start again.
The bug is only apparent when the overall admin default is set to New Window.
Gliffy Diagrams
Issue Links
- duplicates
-
MDL-18735
disabledif doesn't work in IE 7
-
- Closed
-
Activity
Just confirming we are experiencing it on 1.9.4 as well but only when using IE (any version).
We found it by the following steps:
1. Add a new link to file
2. Set Window setting to "New Window" and save
3. Edit the resource again;
4. Change window setting to "Same Window" - the "Force download" box is still disabled. Solution at this point is to save and then edit resource again where the "Force download" checkbox is now enabled;
Also confirming we can lock up both boxes as described in the description for this ticket.
FWIW from my initial look at it:
The problem appears to be the javascript that is handling moodleforms disabledIf calls. There is a circular call in mod/resource/type/file/resource.class.php which might be the source of the problems.
$mform->disabledIf('forcedownload', 'windowpopup', 'eq', 1);
...
$mform->disabledIf('windowpopup', 'forcedownload', 'checked');
As far as I can tell it's not a javascript problem, rather the way IE handles it.
Confirmed fixed. Thanks
I've tried the steps listed in the description of this issue on demo.moodle.org and was able to still reproduce this problem.
If you click on "notifications" of demo.moodle.org it indicates that the version being ran is: Moodle 1.9.5+ (Build: 20090612)
As far as I can tell, this has not been fixed an this issue should be re-opened. The jira ticket that this "duplicates" does not look like a a duplicate.
Re-opening,
Thanks Nick for picking this one up, have tested this on Epiphany web browser and confirmed that the issue is still infact present.
The duplicate issue was also a bug with the disabledif Javascript code.
Found out that this issue is not so much JS-related as it is a logic problem in the form definition. I just removed the line that sets the windowpopup default according to the CFG default, and it all seems to work as one would expect.
this issue should be re-opened again! it still didn't get fixed on version 1.9.7+.
Lei, thanks for your comment. I can also reproduce the issue in 1.9.7+, so I'm reopening the issue as suggested.
The fix for MDL-20836 is the cause for this regression.
We must find a way to fix this bug without removing the windowpopup default according to the CFG default.
I can also reproduce the issue in 1.9.9
I find a way to fix this bug.
In the file mod/resource/type/file/resource.class.php within the function setup_preprocessing() when the forcedownload is set we must set to zero the windowpopup as they are mutual excluded.
@ line 741
if (isset($defaults['options']) and $defaults['options'] === 'forcedownload')
I test this solution in a moodle 1.9.8+ with php 5.2.3 and postgresql 8.4.4
Hi Yolanda thanks for the patch.
I've just tested and commit it to Moodle.1.9.
Cheers
Sam
Assigning to Nicolas & adressinf for 1.9.3