Naming conventions for capabilities?

Naming conventions for capabilities?

by John Isner -
Number of replies: 2
I have a friend whose 8 year old son keeps asking me "What are the naming conventions for Moodle capabilities?" I tell him that I will explain when he is older, but he insists on knowing now.

The general format of a capability name is a/b:c. Do a, b, and c have names? For example, would you call a the capability prefix? I'm looking for terminology that I can use in my explanation so that I don't sound like a total ignoramus.

The article Development:Roles mentions two conventions:

  1. The naming convention for capabilities that are specific to modules and blocks is mod/modname:capability where modname is the name of the directory containing the module's source code.

  2. The naming convention for capabilities that are specific to enrolment is enrol/enrolname:capability where enrolname is the name of the directory containing the enrolment plugin's source code

Are there any other conventions? If there are, I can't detect them. Newer capabilities like the ones in gradebook seem like they are starting a new trend...

gradeexport/ods:view
gradeimport/csv:view
gradereport/grader:view

but is this a trend or an aberration?

What, if anything, can I tell about capability scoping from the capability name (e.g., does the b part tell me anything?

Inquiring minds want to know smile

Average of ratings: -
In reply to John Isner

Re: Naming conventions for capabilities?

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi!

a is the area of Moodle, generally (ie like a path)
b is the actual plugin name
c is the capability


a is restricted by not having punctuation so that's why grade/export became gradeexport.
Average of ratings: -
In reply to Martin Dougiamas

Re: Naming conventions for capabilities?

by John Isner -
Martin,
Thanks for replying. The comments in the access.php files describe two conventions:

1. for capabilities specific to modules and blocks:

[mod/block]/<component name>:<capability name>

where <component name> is the directory name of the mod or block

2. for core capabilities:

moodle/<capability class>:<capability name>

(the comments don't define "capability class")

I think you described (1), and now I understand the oddball naming of gradeexport.

I'd really like to understand convention (2). Scanning all the core capabilities in lib/db/access.php, I found 14 classes:

legacy site user role category
course blog calendar question grade my notes tag block

So (for example) I'd like to understand the sense in which "course" is a class. Can we say class is related to the scoping of the capability? I.e., that a course capability is only useful in a course context? For some of the classes, this is true. But then role, grade, tag, and several others, don't correspond to permission contexts, so I'm baffled.

Maybe it's wrong for users to try to look for meaning in core capability names.
Average of ratings: -