Moodle

Capability definition should include list of contexts where usable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.7
  • Fix Version/s: 1.9.3
  • Component/s: Roles / Access, Usability
  • Labels:
    None
  • Affected Branches:
    MOODLE_17_STABLE
  • Fixed Branches:
    MOODLE_19_STABLE

Description

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

Issue Links

Activity

Hide
Petr Škoda (skodak) added a comment -

CONTEXT_ANYWHERE could have value 0

Show
Petr Škoda (skodak) added a comment - CONTEXT_ANYWHERE could have value 0
Hide
Eloy Lafuente (stronk7) added a comment -

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

Show
Eloy Lafuente (stronk7) added a comment - 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
Hide
Petr Škoda (skodak) added a comment -

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.

Show
Petr Škoda (skodak) added a comment - 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.
Hide
Petr Škoda (skodak) added a comment -

Instead of crating new context for everywhere we could just skip the definition in access.php

Show
Petr Škoda (skodak) added a comment - Instead of crating new context for everywhere we could just skip the definition in access.php
Hide
Petr Škoda (skodak) added a comment -

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

Show
Petr Škoda (skodak) added a comment - 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
Hide
Anthony Borrow added a comment -

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

Show
Anthony Borrow added a comment - 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
Hide
Petr Škoda (skodak) added a comment -

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)

Show
Petr Škoda (skodak) added a comment - 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)
Hide
Petr Škoda (skodak) added a comment -

toto: document in coding guide somewhere

Show
Petr Škoda (skodak) added a comment - toto: document in coding guide somewhere

People

Vote (1)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: