Issue Details (XML | Word | Printable)

Key: MDL-7859
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Petr Skoda
Reporter: Petr Skoda
Votes: 1
Watchers: 6
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Capability definition should include list of contexts where usable

Created: 11/Dec/06 05:21 AM   Updated: 30/Jul/08 12:37 AM
Return to search
Component/s: Roles, Usability
Affects Version/s: 1.7
Fix Version/s: 1.9.3

Issue Links:
Relates

Participants: Anthony Borrow, Eloy Lafuente (stronk7) and Petr Skoda
Security Level: None
Resolved date: 25/Jul/08
Affected Branches: MOODLE_17_STABLE
Fixed Branches: MOODLE_19_STABLE


 Description  « Hide
Currently there is a lot of confusing where each capability can be assigned, the main problem is that in CONTEXT_SYSTEM are capabilites that can be assigned everywhere but also some can be assigned only at at certain levels such (ex. blog capabilities at CONTEXT_SYSTEM only).

I am proposing a simple rule that would make things much easier to understand, both for developers and users:
        **** In capability definition (access.php file) contextlevel means the lowest level (== the highest number) where capability can be assigned. ****

Steps to implement:
1/ create new context level CONTEXT_ANYWHERE (any better name??) with value 100 (or higher)
2/ review all capability definitions and fix context level - CONTEXT_SYSTEM seems to be used too often
3/ fix role definition and overide gui to list the capabilities properly and explain the levels where each capability is applicable
4/ add diagnostic checks in debug mode to verify that capabilities are not used on lower levels than intended - it would catch some nasty bugs

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Petr Skoda added a comment - 05/Mar/07 08:36 AM
CONTEXT_ANYWHERE could have value 0

Eloy Lafuente (stronk7) added a comment - 11/Mar/07 08:13 PM
I wouldn't add more false" contexts at all.

Pasted from chat with Petr...

1) Define applicable contexts (by LISTING them) for both roles and capabilities (some tricks like empty = ALL... and, perhaps other posibilities like, "recursively down" and "recursively up" to save long definitions could be used).
2) Apply all them to 1.9, with a PERFECT migration script.
3) Introduce such script in 1.8 to be able to pre-detect errors (admin menu), not to execute the migration.

2cents (one from me and another from Petr) :-D


Petr Skoda added a comment - 13/Mar/07 07:35 AM
List of capabilities that should be fixed:

changed context:
moodle/user:loginas - CONTEXT_SYSTEM

moodle/site:approvecourse - CONTEXT_COURSECAT
moodle/course:create - CONTEXT_COURSECAT

moodle/role:switchroles - CONTEXT_COURSE
moodle/blog:view - CONTEXT_COURSE

no context == everywhere
moodle/site:accessallgroups
moodle/site:viewfullnames
moodle/role:viewhiddenassigns

Remove - replaced by overides in frontpage course and normal backup/restore roles:
moodle/site:import
moodle/site:backup
moodle/site:restore

Capability upgrade code finished and tested - see MDL-8868.


Petr Skoda added a comment - 13/Mar/07 07:36 AM
Instead of crating new context for everywhere we could just skip the definition in access.php

Petr Skoda added a comment - 28/Apr/08 04:46 PM
We could implement this as bitmask while keeping backwards compatibility in definition. Each bit would specify context where capability is usable.
This would also require to add hooks for modules and blocks to specify which core caps they use.

Benefits would be:

  • the list of capabilitites would not have "random" order anymore
  • ppl could see more easily applicable contexts for each cap (prvents course create capability overriding in course)
  • this could help with detection of logic problems in code (warning if used in different context)

Expected time needed for implementation: 1 week


Anthony Borrow added a comment - 09/Jul/08 03:15 AM
David - What is it that you envision Laia being able to do with this issue? I believe that some work was done to improve the UI for working with roles although I do not recall who had worked on that, what the status of that work was, and whether it has been incorporated into 1.9 or HEAD. I think it would be good if we could help focus Laia's work and wonder if this might not be outside the scope of that unless there were something particular you had in mind for her to do with this. Peace - Anthony

Petr Skoda added a comment - 25/Jul/08 06:03 AM
this should be mostly solved, context levels should be mostly fixed now and there is an option to specify extra caps for blocks and modules, the user context hacks are hardcoded for now, we might improve the user context in 2.0 by adding default overrides (not sure is it is a good idea though because it might have major perf problems)

Petr Skoda added a comment - 30/Jul/08 12:37 AM
toto: document in coding guide somewhere