Non-core contributed modules

I'm seeing the same behavior under Moodle 1.9.1+ (Build: 20080702) and Feedback (2007072500). This was on a clean install of Moodle 1.9.

I should note that I'm running the patch from CONTRIB-346 as well.

http://tracker.moodle.org/browse/CONTRIB-346

I have been unable to reproduce this on a clean install on 1.9.2 (Build: 20080716).

This bug is now affecting my 1.8.3 production Moodle server as well. Restoring a database backup from before the problem occurred did not fix the bug.

I know of another institution that was having this same problem in 1.8.2, but it cleared up when they upgraded to 1.9.

When I turn on debugging, I get:

Error: Invalid context creation request for level "80", instance "22".

• line 1735 of lib/accesslib.php: call to debugging()
• line 1894 of lib/accesslib.php: call to create_context()
• line 117 of blocks/quickmail/block_quickmail.php: call to get_context_instance()
• line 51 of blocks/quickmail/block_quickmail.php: call to block_quickmail->check_permission()
• line 681 of blocks/moodleblock.class.php: call to block_quickmail->get_content()
• line 240 of lib/blocklib.php: call to block_quickmail->is_empty()
• line 79 of course/format/topics/format.php: call to blocks_have_content()
• line 205 of course/view.php: call to require()

This appears to be related to http://tracker.moodle.org/browse/MDL-11814 .

I (temporarily, and not very elegantly) resolved the problem by going into the block code and commenting out the line where it checks for permissions, which is a pretty clunky work-around. I'd rather have it check permissions correctly.

See the thread on this here: http://moodle.org/mod/forum/discuss.php?d=97349#p429935

Anyone ever find a fix for this? I to fixed it be commenting out the permissions check, BUT now anyone in the course can use the block, not just instructors. We want to use Quickmail as a sticky block, but still retain the ability to allow instructors to control if students can or cannot use the block.

I also notice that if as the instructor if I attempt the change the setting for Allow students to Quickmail from No to Yes I get an error (in debug mode):

Trying to get property of non object <MOODLE_HOME>/blocks/quickmail/config_instance.php on line 26

So the problem is that pinned blocks are now required to use CONTEXT_SYSTEM, not CONTEXT_BLOCK for permissions.

Found the solution(s). Ok, bear with me here:
In block_quickmail we change the check_permissions so that it check the right context for our pinned mode. In get_content we add 'pinned=1' to the end of the links, so that we know if it is a pinned block on the receiving end.

This will get the block to diplay in the course.

Now in the block itself.
In email.php we check for the pinned variable in the url and use the pinned block instance if it is.
In email.html we need to add the pinned variable to the form
We add pinned=1 to the various urls in emaillog.php and tabs.php

Look at the attached patch for full details

As for why some can't reproduce:

sticky blocks are stored in block_pinned, and are given an id. In my case 18.

Now in the block_instance table, if you happen to have a standard block with that same id (18 in my case), it won't through the display errors. But if there isn't a row with that id in block_instance, then you will see the errors.

It's just happenstance as to if there is a collision or not, except for that older installs are more likely to have the lower numbered block_instance entries removed (as courses are deleted or edited), but on most sites blocks_pinned would be pretty static, so the ids would be on the low side.

This appears to fix the problem on a vanilla 1.9.3 instance. The reason it doesn't always break (thanks to Eric for the pointer), has to do with mdl_block_instance and mdl_block_pinned. If there's the id assigned to the pinned instance is found mdl_block_instance (even if they're completely dissimilar) then the problem doesn't occur. I don't quite understand why, but using this knowledge I was able to break the system in the first place.

I applied the patch as specified above and as an admin the Sticky Quickmail block seems to be working. But, when I actually login as a teacher, I still can't see it -despite having the Quickmail Can Send permissions enabled. Am I missing something?

The problem is that sticky blocks now use the system context, meaning that even if the user is a teacher in the course, at the system level they are likely a much lower role (like authenticated user or something), meaning that you would have to give the privilege to every user on the system. In order for it to be sticky, and only available to students, you would need to modify the spots where it does the context lookup, and have it look up the current course context and see if the user is a teacher, but you would more or less have to hardcode this change - i think

-eric