|
I think we should create a new context for pinned blocks....
Petr Skoda made changes - 16/Aug/07 04:52 AM
Mike Churchward made changes - 16/Aug/07 04:53 AM
...and just so we understand the issues here, if I DO assign a role or override a role to a sticky block, I actually may be assigning or overriding to a completely different block on a different page.
Mike Churchward made changes - 16/Aug/07 04:57 AM
Petr Skoda made changes - 16/Aug/07 05:11 AM
I don't think introducing a new CONTEXT will work. Context's are element specific - BLOCK, COURSE, etc. A block's pinned nature is just a state - that is a 'pinned' block is still a block. How would we add new capabilities to blocks? Would we need to add capabilities for both CONTEXT_BLOCK and CONTEXT_BLOCKPINNED?
I think the better fix is to get rid of the 'block_pinned' table and add a 'pinned' field to the 'block_instance' table. Hmm ....
I do agree that block_pinned could be better re-implemented with a single new column in block_instance, just for increased simplicity alone. About the contexts, it's a bit tricky to think about since the one "instance" appears site-wide within various other contexts, and so may inherit different permissions from the various parent contexts. Do we process all this like a normal block, effectively treating each place it appears as a sort of virtual instance? Or are pinned blocks an exception to heirarchy rules, with their own context under SYSTEM level? Needs some thinking about.
moodler committed 1 file to 'Moodle CVS' - 24/Aug/07 10:17 AM
In the meantime I've removed the roles assign button from ever showing on sticky/pinned blocks.
I'll file a new bug for improving sticky blocks.
Martin Dougiamas made changes - 24/Aug/07 10:18 AM
moodler committed 1 file to 'Moodle CVS' on branch 'MOODLE_18_STABLE' - 24/Aug/07 10:23 AM
Martin Dougiamas made changes - 24/Aug/07 10:24 AM
Martin Dougiamas made changes - 24/Aug/07 10:27 AM
From what I can tell, the only reason that pinned blocks are in a separate table is to manage the positions easier. If that's true, they could be moved to the same table and just rewrite the code to deal with position issues.
Alan Trick made changes - 18/Oct/07 07:05 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Investigating further...
Ah. I see why. The pinned blocks still use 'CONTEXT_BLOCK', but are stored in a separate block table than blocks. Blocks are in 'block_instance', while sticky blocks are in 'block_pinned'. This means that the 'get_context_instance' function is getting records with an instance id referring to the wrong table. Worse yet, they may actually create a context id record for the wrong block!
Note that the original complaint said that icon had an empty context id. Unfortunately, it may not be empty if it finds a regular block entry with the same id as the sticky block.