The 'flexible' in flexible roles does not come from their non-existent abilities to support granular access divisions, but from the fact that the roles are now in the database and can be renamed, disabled, and restored. It was thought that someday, the 'flexible roles' label could change to something simple like 'roles'. The system name for these 'flexible role' entities did not suit the seemingly more appropriate label of 'custom roles' because, in order to support use cases like being able to rename roles, and to prevent having to deal with two types of roles separately (i.e. custom vs shipped), every role is a flexible role, each of which can be associated with a user by way of the 'roles' table.
I think your distinction between roles and access object groups is important. Access rights to certain parts of the system are what is really being associated with a user when a role is assigned to that user in PKP. I think using the term role has worked well so far, as it is a familiar concept to most (i.e. when logging-in in the morning, people identify more closely with 'it is my duty to perform the actions associated with this role'); however, I agree that, at the system level, using the more security-oriented language is more appropriate, as it reserves the term 'roles' for a different purpose and brings the terminology closer to what programmers might expect.
The use cases we have so far only involve intersection-free roles. All 'press-type' roles have access to the same operations in the Role handler. The 'author-type' roles are a bit of a special case in that they need access to author functions, which seemingly boils down to a routing issue. Besides creating more intuitive role spaces, these synonyms do not pack much else in terms of functionality at the moment, but I think they provide a basis for extension and an implementation of something that allows users to be more creative with roles.
In general, I think that it would be good to work in the direction of your proposal, Florian. Pre-handler authorization checks in the dispatcher, as far as I can tell, would be great. Also, since we might not have the energies for another overhaul at this stage in the development of OMP, we could review what we have to make sure that it'll be easily re-factored into new security patterns in the future and that it contains the terminology we'll be able to put up with, while at the same time coming up with a definite approach to the more general design issues. Building custom roles, in the sense that you're describing, should definitely be part of the plan, but an overhaul probably isn't necessary for the current use cases.
Tylkkn 20:06, 7 January 2010 (UTC)