Difference between revisions of "SoC improve configuration gui"
m (some config options could also benefit from rewording)
|(One intermediate revision by one other user not shown)|
Latest revision as of 14:30, 20 March 2010
This is a continuation of the 2007 GSoC project that resulted in the current Configuration GUI. This follow-up project is aimed at implementing some of the ideas that didn't make it into the initial version. This is also a good opportunity to do a reality check of the existing GUI and see what's missing and what could be improved.
More Fine Grained Access Control
Currently, only users in Geeklog's "Root" group have access to the Configuration. The idea has always been, however, to make this more fine grained so that, for example, Story Admins could - optionally - have access to configuration options related to stories and story submissions.
Define Config Groups
As a first step, the existing config options will have to be reviewed and grouped to get an idea which options belong together and to which access can be granted. There will certainly be options for which Root access is still required. Plugins should also be allowed to control access to their config options.
Access control should be implemented on a per-option basis. There are various ways how this could be implemented. One obvious solution could be to introduce config.* permissions, e.g. having config.story permissions would give access to config options related to stories (actually, that's probably too broad and should be more fine grained). But there may be other (better) ways to implement this.
Options for which the current user does not have access should not be displayed. Root users should have access to everything, as usual.
- Real-time bounds checks: Some config options are displayed as free-form input fields but really only accept numerical values or a certain range of values.
With over 200 configuration options for the Geeklog core alone, it is sometimes hard to find the config option you're looking for. Being able to search for an option would come in handy.
While this could be implemented as a "traditional" search, something more interactive could make this a really useful feature. This would also be another case that could benefit from the adoption of jQuery.
New UI Elements
Currently, the Configuration GUI supports dropdowns, input fields (one-line and multi-line) and array-type fields.
Many of the dropdowns, however, only offer true/false options and may be better represented as radio buttons or checkboxes. Review the existing options and implement support for the additional types where required.
There may be other new UI elements that we may want to implement to better represent some of the available options. A pair of fresh eyes (belonging to someone who doesn't know about the $_CONF heritage of the Configuration) could help identify those ...
And then there are a couple of minor details that should be looked into, e.g.
- re-grouping / re-arranging / re-wording options
- provide direct links to config sections, e.g. for plugins
Level of Difficulty