Hi Mark, I'm not sure I'm following.
We were specifically asked to separate Constitutionally-defined role names and Constitutional information from the collective information. And that's what we will do. We will remove the Constitutionally-defined role names from the Community Group collective. And Constitutional information will only be stored in the Community Group Electorates. The basic architecture of Auth remains the same. It defines a core set of roles that each application interprets as it needs to. With this change, the Community Group role names are not associated with information in the Constitution, so no application will map anything to the Constitution using the Auth role names. In the case of XWiki, it will map XWiki-specific privileges to the role names in Auth. Thanks. Bonnie On 08/25/09 06:33 AM, Mark Martin wrote: > Bonnie Corwin wrote: >> Hi, >> >> There have been multiple discussions recently regarding the current >> implementation of Auth and how it relates to access control for >> applications such as XWiki. Members of the Website Development team >> attended the OGB meeting on Aug 20 to understand in detail the OGB's >> concerns about the current implementation. These center around the >> use in Auth of the Constitutionally-defined role names of Contributor >> and Core Contributor in the Community Group collective. >> >> To address the OGB's concerns, the following changes will be >> implemented before the Phase 2 transition to XWiki: >> >> 1. Rename the existing Community Group roles as follows (they will be >> the same as those in the User Group collective): >> >> Core Contributor -> Leader >> Contributor -> Affiliate >> Participant -> Participant (unchanged) > While the name change does address the "what's in a role name" confusion > issue, I'm still confused by this approach. I know this has been > discussed to death, but I still see a large gap that the website group > seems unwilling to fill. As was mentioned at the last OGB meeting, the > website team does not want to produce a rights management system. > They'd like to produce a simple authentication system that exposes > /some/ rights, but those rights are strictly a simple mapping to the > identity's role in the (current) constitution. Over and above that, it > is up to client systems to implement their own rights management system. > > And for XWiki, there won't be such a management system. What's been > proposed is that there is no mapping, or rather, that the mapping is the > simplest one possible -- 1 role as defined in the constitution = 1 role > in the wiki site. This doesn't map to how the site is being used > currently, and as has been mentioned ad naseum already, doesn't seem > tenable. It's too coupled, not scalable, and not flexible enough to > allow editors and content publishers some room to do their work > effectively. Despite assertions to the contrary, I believe few people > outside the website group seem convinced. > > Does the website community plan to fill this gap? Is the "community" > even a stakeholder in deciding requirements for the website community? > Past experience would indicate a big *no* to that last question -- it'd > be nice to get a straight answer on that, regardless.
