Thank you for replying to my post. If you don't mind, I'd prefer to hold off discussing your second scenario until we resolve the first one.
No. B will still be more local, and win.
But since the override to A is done in the child context, the override "brings down" (i.e., localizes) one or more permissions into the child context, and these should compete directly with B. Otherwise, it makes no difference whether you override A in the parent context or the child context, which is completely unreasonable.
I am not advocating that the entire role A should be localized, but only those capabilities that are modified by the override.
Say I am a Teacher in a course context and I assign myself the role of Student in a particular quiz. When capabilities a clash, Student wins because it is more local. Good. So now I can now "Attempt quizzes" (Teacher is prevented, Student is allowed, Student wins). But because "Preview quizzes" is not set in Student, I inherit the ability to "Preview quizzes" from Teacher.
Now it gets interesting. There is a bug/feature in quiz, that will refuse to let you Attempt if you have both Preview and Attempt, so I must somehow turn off Preview.
- If I override Teacher in the module context, your rule says "Sorry, the Student assignment is more local than the Teacher override, so I'm going to ignore your override."
- If I override Teacher in the course context, setting Preview = prevent, I can't preview any of my quizzes!
If the algorithm treated the override as local, my problem would be solved since the capabilities would be resolved using the "same context rule" Prevent (-1) + Not set (0) = Prevent (-1).
It turns out that it actually DOES work this way in 1.9 beta 4 (see this discussion
). I do not understand the last couple of paragraphs of your post above. Are you saying this will change?