Chris, I put back the forum moderator example. I think it was intentional. We want to get people thinking outside the box of what previous versions were capable of.
The list of capabilities for some activities should include viewing as a separate capability since it is a distinct action from editing or taking part, for example
legacy support for isstudent() and isteacher()
We could provide legacy support for modules (and core) to continue using isstudent() and isteacher() calls, by replacing these with stubs that simply wrap the new access control API and feed in the proper parameters. This might help reduce the initial effort (i.e., you don't HAVE to update every. single. module. at first, just the ones most affected by this API change. then, as time allows, and as modules are being updated anyway, migrate them to the new API)
almost forgot - totally looking forward to this feature. any ETA?
What are the legacy capabilities for?
I've been reading the Roles documentation, and my a lot of work going on in here! Keep it up! I might be understanding something incorrectly as I can't figure out what the legacy capabilities are for? I thought that Roles are sets of capabilities. There might/should be Roles for all of the "legacy roles", which would then have the default set of capabilities matching the capabilities in 1.6. What are the "legacy capabilities" then? --Samuli Karevaara 07:27, 1 September 2006 (CDT)
Page too long?
I think this page is a bit too long and could profit from some refactoring, for example reducing some redundancies with other pages like Roles and modules or integrating Local customisation. --Frank Ralf 17:14, 27 March 2009 (UTC)