Moodle

"Force download" unable to be changed once selected

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.9, 1.9.1, 1.9.2
  • Fix Version/s: 2.0
  • Component/s: Resource
  • Labels:
    None
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

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.

Issue Links

duplicates

Bug - A problem which impairs or prevents Moodle from functioning correctly. MDL-18735 disabledif doesn't work in IE 7

  • Blocker - Blocks development and/or testing, prevents Moodle from running (applicable to bugs only)
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed should not be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Eloy Lafuente (stronk7) added a comment -

Assigning to Nicolas & adressinf for 1.9.3

Show
Eloy Lafuente (stronk7) added a comment - Assigning to Nicolas & adressinf for 1.9.3
Hide
Permalink
Tim Lock added a comment -

Also applies to 1.9.4+ (Build: 20090303).

Show
Tim Lock added a comment - Also applies to 1.9.4+ (Build: 20090303).
Hide
Permalink
Shane Elliott added a comment -

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.

Show
Shane Elliott added a comment - 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.
Hide
Permalink
Sam Hemelryk added a comment -

Confirmed fixed. Thanks

Show
Sam Hemelryk added a comment - Confirmed fixed. Thanks
Hide
Permalink
Nick Thompson added a comment -

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.

Show
Nick Thompson added a comment - 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.
Hide
Permalink
Sam Hemelryk added a comment -

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.

Show
Sam Hemelryk added a comment - 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.
Hide
Permalink
Nicolas Connault added a comment -

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.

Show
Nicolas Connault added a comment - 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.
Hide
Permalink
Lei Zhang added a comment -

this issue should be re-opened again! it still didn't get fixed on version 1.9.7+.

Show
Lei Zhang added a comment - this issue should be re-opened again! it still didn't get fixed on version 1.9.7+.
Hide
Permalink
Helen Foster added a comment -

Lei, thanks for your comment. I can also reproduce the issue in 1.9.7+, so I'm reopening the issue as suggested.

Show
Helen Foster added a comment - Lei, thanks for your comment. I can also reproduce the issue in 1.9.7+, so I'm reopening the issue as suggested.
Hide
Permalink
Yolanda Ordoñez Rufat added a comment -

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

Show
Yolanda Ordoñez Rufat added a comment - 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
Hide
Permalink
Yolanda Ordoñez Rufat added a comment -

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')

{ $defaults['forcedownload'] = 1; $defaults['windowpopup'] = 0; }

I test this solution in a moodle 1.9.8+ with php 5.2.3 and postgresql 8.4.4

Show
Yolanda Ordoñez Rufat added a comment - 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') { $defaults['forcedownload'] = 1; $defaults['windowpopup'] = 0; } I test this solution in a moodle 1.9.8+ with php 5.2.3 and postgresql 8.4.4
Hide
Permalink
Sam Hemelryk added a comment -

Hi Yolanda thanks for the patch.

I've just tested and commit it to Moodle.1.9.

Cheers
Sam

Show
Sam Hemelryk added a comment - Hi Yolanda thanks for the patch. I've just tested and commit it to Moodle.1.9. Cheers Sam

People

Vote (13)
Watch (14)

Dates

  • Created:
    Updated:
    Resolved: