Moodle

This is actually a feature of Roles in Moodle 2.0 already, but I don't think we can backport that stuff to 1.9 easily...

I think I could add at least a list of contexts

yes, sam (or tim?) implemented this in 2.0dev - I remember OU proposed this.
Internally the changes very not big, but it will surprise some ppl when they upgrade to 2.0 - in fact my main motivation was to try to warn ppl abusing the do anything capability because it will not be allowed in 2.0

Petr, can you explain/document what this check is really about? What exactly are the risks in someone having doanything at course level? Several examples would be good.

I really think we should not call those "unsupported roles" as that has connotations, if we have to say something about this perhaps it would be better to say "not recommended".

Each role is intended for specific contexts:
Student - works best at course context, problematic and sometimes buggy if used in course category or system; can not work at all in user context
Teacher - course or category; can not work in user context at all
Logged in user - only system context; no manual role assignment

The unsupported admin role assignment is a bit special, originally it was intended for main system administrator only - this is the most powerful role that should not be used for daily work as normal teacher.

I keep repeating that course enrolments are not implemented in an optimal way, there are very many problems since 1.7.0 Somehow people found out they can "workaround" some enrolment related problems by assigning altered Administrator role at the course or course category level to normal teachers - this is not a good idea because it will not probably work in 2.0 if we decide to rewrite enrolment code.

The short answer is: use administrator accounts for server administration only, for teaching use normal teacher accounts.

This means admins should have two different accounts. Once we implement web services and somebody creates remote moodle console it should not be necessary to log in as server administrator at all

Would it be better to say - "Not recommended" instead of "Unsupported" ?

reopening, "Not recommended" was proposed by Martin too in partner forum

I discussed this more with Martin today, we need some more explanation in docs ...

As far as I can understand what Petr wrote, seems like some "unsupported" role assignment do not work as expected in every context

if it is true, they are not Unsupported nor Not recommended. They should be avoided. Isn't it?

Petr, thanks for your explanation which I've added to http://docs.moodle.org/en/report/security/report_security_check_riskadmin

Anyone, please feel free to edit / add to the explanation

Thanks Helen and Petr.
Some roles are described as not working or buggy if assigned on some contexts. Should we still allow assigning such roles in those context?

The problem is not the role itself, but the capabilities it has - the context info should be already present in capability description, if not we should add it there.
We can also improve description of roles.

Thanks, Petr, I understand your point: capabilities of a role in some context may be buggy or not working.

Should we expect those buggy/not working capabilities when assigning unsupported roles will be solved in the near future? If yes, no problem, we can safely say "it will be solved".

If not, are we sure it make sense allowing people to keep assigning buggy/not working role ?

Wouldn't be better to disallow buggy/not working role assignment until (and if) all context are correctly supported? They are buggy/not working, aren't they?

It is fixed in 2.0 - each role has a list of contexts where it should be used
If you create your own or modify existing you need to study capability descriptions+doc in order to know where/how to use - I doubt any automated tool may help with this - admins need to educate themselves

Thanks Petr. I found the setting in 2.0

Some questions:

1. block context is not marked for no role. It is always unsupported ?
2. if we know a set of capability is buggy or not working in a given context, even studyng and understanding things will not help. Again, are we sure we want to keep people assigning buggy capabilities ?