Development talk:Roles

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

choice_canviewresults

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)

No answer yet... This was also asked in the forums. --Samuli Karevaara 04:43, 18 January 2007 (CST)