The point (state or level) is what we call the context
. It is where you currently are in the site - where the web page you are currently looking at is. The way to think of this is like a file path. If you are thinking about a word document on your hard disc, it might be in folder "VLE docs", but that is acutally
C:\Documents and Settings\timhunt\My Documents\VLE docs\spec.doc
Similarly, this forum is Forum: Roles and Capabilities, but actually, that is
Site: moodle.org/Category: Community Discussion (in English)/Course: Using Moodle/Forum: Roles and Capabilities
You don't just have a single role. The most normal situation is that you have two. At the moment (assuming you are logged in) you are assigned
the role "Logged in user" in context Site: moodle.org. Since this forum is inside the site, that role applies
here. Second, you have been assigned the role "Moodler" in context Course: Using Moodle (this happened when you first came here, were asked if wanted to enrol, and clicked yet). Since this forum is inside that course, that role applies here too. So (as I said was normal) in this forum you have two roles. If, however, you go and look at the list of courses in category Community Discussion (in English)
, then you will only have one role (Logged in user) there, because that category is outside the course. If you were not logged in when looking at this forum (or anywhere else), you would just have one role "Guest", assigned in context Site: moodle.org, and so applying here too.
What a role
actually gives you is a defined permission
for each capability
. A capability is a specific thing that you might, or might not, be allowed to do. For example mod/forum:viewdiscussion, or mod/forum:replypost. A permission on that capability is basically either Allow or Prevent (I am simplifying slightly here).
What actually determines whether you can do a particular thing in a particular context is the computed permission you have for that capability. This is a combination of the permissions you have from each role that applies in this context. The precise rules here are complicated but roughly it is "Count +1 foreach allow, -1 for each prevent. If the total is > 0, the computed permission is allow; if the total is < 0, it is prevent; in the case of a tie, apply some tie-breaking rules."
There is one more concept to understand, and that is overrides. Above I talked about the defined permissions for a role. Normally, roles are just defined in the site context (for example saying that Moodlers are allowed to mod/forum:replypost), and that definition applies everywhere. But suppose in one particular forum (e.g. the news forum) you want to change the definition, so Moodlers can't reply there. Well, you can do that by overriding the Moodler role in the context of that forum to change the permission.
Overrides just make the "complicated rules for working out the computed permission" more complicated. Fortunately, you don't really need to understand these rules. They normally do what you expect (and the reason they are very hard to write down precisely is that human common sense is very hard to describe and explain to a computer).
P.S. the terms I have put into bold are a combination of existing ones (context, role, assign, permission, capability, override) that are currently used in the code and user interface and explained on MoodleDocs; and some I made up just now because I thought they made this explanation clearer (applies, defined/computed permission).