I need to get rid of a “note to self” on my desk, so here we go for the first major change planned for the upcoming PointComma 4: the security system. Renaud is currently cleaning up the code base, and building an extremely powerful application, but we have chosen not to change the security model for lack of information regarding what needs to be done (what problem are we solving?).
Here is the problem: the current type-based security controls are good, but are far from good enough. Particularly, they do not easily allow authorizing a user on a page and sub-pages, but not the parent, while this would be a very simple, very obvious feature.
However, the other issue is that it would be very difficult to create an authorization system as generic as the rest of the framework. Typically, if you start introducing the concept of “pages” into PointComma, it stops being a generic application framework, and you’ll start limiting the applicability of some of the features to a subset of the managed objects. That’s no good.
So we’ll have to find a way to let the site creator define rules for determining wether a user may or may not edit or modify an item. Some way to create authorization flags (as part of roles) with no effect on the system, but that can be used by the site creator.
This will also require to close the default admin interface to all but the site creator.
A few ideas that also need to be worked in:
- add a “parent” or “tree builder” characteristic format, to support the creation of hierarchies more easily
- add data constraints that are enforced in PHP at write-time and in JavaScript in edit forms
- SPIP text markup will need to be more tightly integrated, and we’ll have to ensure that it is possible to override its various “hook” functions (such as the routine for including images or creating links)
We’re on a roll: Renaud added type inheritance, which is a very elegant feature, and the new error management system is brilliant. We are missing a more convenient debugger, but that will be done soon.
Only annoying element I see now: we’re missing manpower behind the documentation. This is the plague of all open-source projects…